LINUX.ORG.RU

Тендер на создание средства для конвертации HTML+CSS2 в ODT


0

0

OpenDocument Fellowship обьявило тендер на создание средства для конвертации из HTML+CSS в ODT. Бюджет оценивают в 11,5 тысяч долларов США.

Желают видеть программу на C/XSLT/скрипт на Perl, кроссплатформенную, использующую стандартные библиотеки, но минимально возможное их количество.

Заканчивают прием заявок 23го сентября.

Мне кажется, что тут есть шанс немного заработать для тех, кто в курсе дел, не так ли?

Рекомендуют слать им свои предложения на следующий емэйл:

projects@opendocumentfellowship.org

>>> Подробности

Ответ на: комментарий от Gharik

> жабакодерам

прочитал не как "жаба-кодерам" а как "жабако-дёрам" :)

Kardinal
()
Ответ на: комментарий от ero-sennin

достаточно заюзать движок мозиллы/firefox, которые сами по себе кросплатформенные. Этот движок дёргать можно кучей способов.

anonymous
()
Ответ на: комментарий от Gharik

Пока что в основном кроссплатформенный софт пишется на Си/С++, а вовсе не на жаве. И в самом деле не стоит засорять тяжелыми фреймворковыми зависимостями маленькую утилиту по конвертации.

Displacer ★★
()

Во млин какой бюТжеДъ Агромный аж конкурЗ! Это 3 месятса работы двух прагромисдоф. Ну и нанили бы их.

DOKA
()

imho ничо сложного (к жабабыдлокодерам не относится)... если нужна либа так можно на qt4 (QDom* для odt и QXml* для html, css парсить регекспами :) ). а если вообще нужно шоб работало, так perl и вперед :)

ps: всё больше склоняюсь к идее купить вторую usb-клаву и поставить ёё на русскую раскладку -- ппц переключаться достало ;)

arsi ★★★★★
()

Что, мужики, кто со мной, писать сабж на CDuce? ;)

ero-sennin ★★
()
Ответ на: комментарий от arsi

>это 8 ящиков пива и за месяц будет готово %) У тебя есть шанс заработать. Думаю тут не много людей найдется которые действительно представляют какой там обьем работы и какого уровня квалификация должна быть.

anonymous
()
Ответ на: комментарий от arsi

>> Это 3 месятса работы двух прагромисдоф.

> это 8 ящиков пива и за месяц будет готово %)

Ребят, вы все такие умные и опытные - вот бабло фактически просто так валится. Беритесь, а потом расскажете нам про халяву, которую вам подбросили тупые америкосы. Хоть позавидую потом.

plm ★★★★★
() автор топика

Вам не кажется что работа это чисто механическая?
Предлагаемое вохнаграждение тоже не джекпот, хотя и не символическая. 
В чём прикол?

ezhikov
()

Сейчас подумал: перегонять из XHTML в ODF и обратно довольно просто, т. к. они очень похожи. А вот мелкомягкий OpenXML тут жостко пролетает. И это радует, друзья. :)

ero-sennin ★★
()
Ответ на: комментарий от plm

> Ребят, вы все такие умные и опытные - вот бабло фактически просто так валится. Беритесь, а потом расскажете нам про халяву, которую вам подбросили тупые америкосы. Хоть позавидую потом.

так а в чем бабло-то? и где халява? 11 килобаксов -- эт мелоч для америкозов. там оклад программера 3-5к. при том шо они это зделают отделом за 2-3 месяца, при этом будут жутко шаро**биться (из личного опыта ;) ). так шо шара попадает как раз америкозам: штатным прогаммистам заплатили бы в пол-дюжины раз больше при в два раза больших сроках. а один (шоб нихто не мишал :) ) квалифицированный программер с желанием работать за месяц благодаря ударному труду (и пиву, ессесно :) ) это может запросто осилить... даже не соко за деньги, а просто шоб негрософт обосрать %)

arsi ★★★★★
()

> Timeline
>
> We expect that this project will take in the order of 1 man-month. The project should be completed by November 30.

Довольно наивные у них представления, особенно о необходимых человеко-днях. Хотя, может квалифицированный специалист действительно способен осилить?...

kmike ★★
()
Ответ на: комментарий от kmike

> Довольно наивные у них представления, особенно о необходимых человеко-днях. Хотя, может квалифицированный специалист действительно способен осилить?...

у меня когда-то ушло 3 часа на написания конвертора fb2=>html на perl, причем большее время было потрачено на написание своего xml-парсера, т.к. прилагающийся с дистрибом модуль парсинга безбожно глючил (пропускал тэги).

конвертировать xml-подобний файл в ему-же подобный больших усилий не требует, в основном -- изучения спецификаций, что и будет самое сложное :) (спецификация odf занимает 706 страниц в pdf-е, может к новому году и осилю :) )

ну и с css2 в xml (odf) тоже придется помучиться, но это работа на пару-тройку дней (опять же -- при условии, что спеки уже осилены).

arsi ★★★★★
()
Ответ на: комментарий от kmike

> > We expect that this project will take in the order of 1 man-month.

кстати, когда я отпостил, что один программер за месяц справится, я статью не читал :) просто прикинул исходя из объема работ и количества пива %)

arsi ★★★★★
()

ИМХО, оптимальнее и кроссплатформее всего делать это на XSLT. Тогда зависимости будут минимальные. А поддержка XSLT наверно есть во всех тулзах которые как либо могут это использовать. Например в браузерах во всех есть. Потому скажем смотреть документы из браузера будет очень просто (сделать поддержку в самом браузере) - просто пропустив через XSLT фильтр.

anonymous
()
Ответ на: комментарий от DOKA

>Ну и нанили бы их.

Нфиг двух программеров, когда за те же деньги можно нанять толпу? (Тендер же)

KRoN73 ★★★★★
()

рендерить в битмапы... потом вставлять ... в ODT :) LOL

robot12 ★★★★★
()
Ответ на: комментарий от arsi

>так а в чем бабло-то? и где халява? 11 килобаксов -- эт мелоч для америкозов. там оклад программера 3-5к.

А что, кроме как в Америке, нигде больше программистов в мире нет?

KRoN73 ★★★★★
()

Граждане, считающие, что это все так просто и за пару-тройку дней можно сваять, могут пройти и ознакомиться со знаменитым тестом ACID2 и проникнуться возможными извращениями в HTML/CSS. Одна радость - поддержки OBJECT не требуется, но это только полбеды.

Hint: если бы все web страницы были XHTML-совместимы... а ведь в требованиях четко написано про command-line tool that converts HTML 4.0 + CSS2. А HTML 4.0 - это огромное болото, не говоря уж про то, что большая часть страниц даже с ним-то не совместима.

Но самое главное в требованиях - вот это:

> The result should look comparable to what a standards-based browser like Firefox or Konqueror would render.

Т.е. ребята фактически хотят _качественный_ рендерер HTML в ODT. То, над чем бьются целые команды в Mozilla, Opera, Apple и Microsoft, 1 человек должен написать за месяц. Тут больше даже и добавить нечего.

kmike ★★
()
Ответ на: комментарий от kmike

Не зная, как реализовано применение стилей к ODF, скажу, что предлагаемая задача --- мегагеморрой.

Пропарсить структуру можно даже на С, с учётом исключений и финтов ушами типа игнорирования незакрытых тегов. Вот с CSS-то что делать, а? font-family=Arial; font-weight=bold; не обязательно соответствует заголовку :(

PS: настраиваю чужой сервак, пишу из-под IE

Ay49Mihas ★★★★
()
Ответ на: комментарий от kmike

>Т.е. ребята фактически хотят _качественный_ рендерер HTML в ODT. То, над чем бьются целые команды в Mozilla, Opera, Apple и Microsoft, 1 человек должен написать за месяц. Тут больше даже и добавить нечего.

Замечу, что все же речь идет о конвертации, а не о рендере. То есть сам рендеринг ложится на плечи того средства, которым будет проверяться результат. Что касается незакрытых тегов и css, наверняка есть библиотеки, которые это дело парсят и представляют в виде объектной модели (утверждать не берусь :) )

Соответственно, задача представляется не очень сложной, хоть я ODT и не видел. А если уж и для ODT существует грамотная либа, то дело и вовсе ограничится тупыми "for each ... in ...", и формата знать не надо. Было бы интересно взяться, да в сях слабоват.

jerry
()
Ответ на: комментарий от KRoN73

> А что, кроме как в Америке, нигде больше программистов в мире нет?

а цытируемого текста мы уже не читаем?

"Беритесь, а потом расскажете нам про халяву, которую вам подбросили тупые америкосы."

подсказка: ключевые слова "халява" и "америкосы". вопросы в этом контексте еще будут?

arsi ★★★★★
()

Мне кажется авторы совсем не представляют объем работ... :/

Если бы конечно все страницы состояли из стилей, то еще можно было бы что нибудь придумать, да и там - загонять туда все стандарты отображения, да за такое время, да за такие деньги...

Orlangoor ★★★★★
()
Ответ на: комментарий от Orlangoor

> Мне кажется авторы совсем не представляют объем работ... :/

представляют. совсем.

> Если бы конечно все страницы состояли из стилей, то еще можно было бы что нибудь придумать,

в каком смысле "страницы из стилей"?? это css называется, что являет собой приложение к html и само по себе документом не является.

> да и там - загонять туда все стандарты отображения,

какие еще стандарты отображения? абзац/таблица/объект? так это все в odf есть, просто теги поменять (... ну почти) :) или форматы картинок? так их просто в папочку Pictures скопировать и линки поправить :) , ООо все форматы картинок, разрешенных для применения w3c, поддерживает.

> да за такое время, да за такие деньги...

время достаточное, деньги тоже. повторяю -- этот проэкт не для быдлокодеров, для них это действительно почти невыполнимая задача, но опытный в таком деле программист вложится и в сроки и в требования.

зы: действительно большая проблема будет из скриптами, т.к. в спеках на тот же xhtml сказано одно, а на практике используется совсем по другому (пробовал сделать по спеках, огнелис не понял).

arsi ★★★★★
()
Ответ на: комментарий от arsi

> какие еще стандарты отображения? абзац/таблица/объект? так это все в odf есть, просто теги поменять (... ну почти) :)

"просто тэги поменять" - это примерно "а чо - взять все и поделить". Представляю, какой будет результат - примерно качества того, что выдает links, а то и хуже.
А кто будет учитывать CSS box model, fixed positioning, relative positioning, floats? и каждая из этих вещей может задаваться в 10 местах - в .css, в <head>, в свойствах самого элемента. И приходим к тому, что надо строить DOM object tree (из которого уже генерировать ODT). Т.е. опять же то самое, чем занимаются Gecko и иже с ними.

kmike ★★
()
Ответ на: комментарий от jerry

>>Т.е. ребята фактически хотят _качественный_ рендерер HTML в ODT. То, над чем бьются целые команды в Mozilla, Opera, Apple и Microsoft, 1 человек должен написать за месяц. Тут больше даже и добавить нечего.

> Замечу, что все же речь идет о конвертации, а не о рендере. То есть сам рендеринг ложится на плечи того средства, которым будет проверяться результат.

Ладно, рендеринг - неудачный термин в данном случае. Я про то, что раз качество выдаваемого ODT должно соответствовать качеству рендеринга FF и ему подобных, то конвертер должен быть настолько же продвинутым, как и Gecko.

>Что касается незакрытых тегов и css, наверняка есть библиотеки, которые это дело парсят и представляют в виде объектной модели (утверждать не берусь :) )

Ага, есть: Gecko, KHTML/Webkit и т.п. ;)

>Соответственно, задача представляется не очень сложной, хоть я ODT и не видел. А если уж и для ODT существует грамотная либа, то дело и вовсе ограничится тупыми "for each ... in ...", и формата знать не надо. Было бы интересно взяться, да в сях слабоват.

Просто рекомендую попробовать, зубки быстро пообломаются... ;)
The devil is in the details, как говорят в Англии.

kmike ★★
()

Такое только русские асилят, прям как в анекдоте про проц, "вы не поверите - он ламповый". И использоваться будет только libc, да опционально libm =)

Gharik
()
Ответ на: комментарий от kmike

Поддерживаю. Задача сложная и с кучей подводных камней. Например, очень многие HTML файлы содержат структурные ошибки. Нужно будет такие кривые файлы тоже как-то интерпретировать. Короче, в лучшем случае полгода для создания самой первой версии 1.0, и только если разработчик (или разработчики) окажется достаточно способным, что встречается нечасто... Такое вот мое мнение.

SDE
()
Ответ на: комментарий от jerry

>Замечу, что все же речь идет о конвертации, а не о рендере. То есть сам рендеринг ложится на плечи того средства, которым будет проверяться результат.

Замечу что все же о рендере а не о конвертации - просто таржет девайс не битмап. Термин "конвертация" можно было бы применить, если бы одни стили имели однозначное отображение в другие - подошла бы конвертация. А ее там скорее всего нет - в CSS стили наследуются это раз. Стили могут быть заданы в N метсха - а именно на один и тот же элемент может распространятся стиль парента, у него может быть определено N классов, задан style, плюс может быть конфликтующий параметр тега (width, margin, padding, border, align, etc). Следовательно надо писать нехилый интерпретатор.

Так что...

>Соответственно, задача представляется не очень сложной, хоть я ODT и не видел.

...это ты загнул.

r ★★★★★
()
Ответ на: комментарий от SDE

>Поддерживаю. Задача сложная и с кучей подводных камней. Например, очень многие HTML файлы содержат структурные ошибки. Нужно будет такие кривые файлы тоже как-то интерпретировать. Короче, в лучшем случае полгода для создания самой первой версии 1.0, и только если разработчик (или разработчики) окажется достаточно способным, что встречается нечасто... Такое вот мое мнение.

+1. Проектодатели не представляют сложность работы. В 1 месяц все бы может уместилось у программиста который до этого пару лет с этим возился и имеет наработки и знает все камни. Например у каких нить девелоперов Gecko или KHTML. Им бы нужно было изучить только target device. И то за месяц была бы корявая глючность.

r ★★★★★
()
Ответ на: комментарий от r

> Замечу что все же о рендере а не о конвертации

гы, улибнуло. напомню, что речь идет о получении odf-_документа_ из (x)html-документа, а "Rendering is the process of generating an _image_ from a model, by means of a software program." (http://en.wikipedia.org/wiki/Rendering_(computer_graphics)) Перевести слово image, или сами справетесь? ;)

> CSS

условия применения стиля гуляючи можно переделать в pcre, а путь к элементу будет играть роль строки для наложения шаблона, хотя можно и попроще, если на готовых либах не зацикливаться (ну не писать же собственный pcre-движок?). а наследование стиля от родительского тэга это действительно для вас так сложно? ;)

> Следовательно надо писать нехилый интерпретатор.

ясен пень, что sed тут не проконает :) деньги-то не за красивые глазки давать будут :)

arsi ★★★★★
()
Ответ на: комментарий от arsi

>" (http://en.wikipedia.org/wiki/Rendering_(computer_graphics)) Перевести слово image, или сами справетесь? ;)

Нет - переведите слово "рендеринг" не применительно к computer graphics.

http://lingvo.yandex.ru/en?text=rendering&st_translate=1

rendering 2) перевод, переложение; передача, изложение; интерпретация

>условия применения стиля гуляючи можно переделать в pcre

Наверное потому бровзеры только-только начали проходить acid2, что это гуляючи можно сделать регекспами?

>а наследование стиля от родительского тэга это действительно для вас так сложно? ;)

Я про то, что стиль в стиль CSS -> ODF не отображается, и как там указано for-eachами пробежаться неполучится. Даже XSLT тут покатит хреновенько, разве что как google сделал ajaxslt.

Дык это, вперед - 11 кусков зелени - токо пообещайте им to reach the deadline - и проект ваш. Халява же?:)

r ★★★★★
()
Ответ на: комментарий от arsi

> > Такое только русские асилят, прям как в анекдоте про проц, "вы не поверите - он ламповый". И использоваться будет только libc, да опционально libm =)

> зачем???? синусы/логарифмы бум считать?? :)

Там будет хитрым образом зашито аппаратное ускорение через всякие SSE/altivec ;)

Gharik
()
Ответ на: комментарий от r

> Проектодатели не представляют сложность работы. В 1 месяц все бы может уместилось у программиста который до этого пару лет с этим возился и имеет наработки и знает все камни. Например у каких нить девелоперов Gecko или KHTML. Им бы нужно было изучить только target device. И то за месяц была бы корявая глючность.

Похоже, что не представляют или просто надеются на чудо :) Один мой знакомый говорил, что ему нужно три месяца только для того, чтобы вникнуть в саму задачу...

SDE
()
Ответ на: комментарий от arsi

> речь идет о получении odf-_документа_ из (x)html-документа, а "Rendering is the process of generating an _image_ from a model, by means of a software program." (http://en.wikipedia.org/wiki/Rendering_(computer_graphics)) Перевести слово image, или сами справетесь? ;)

Дык, сначала эту "model" надо получить. Самое сложное в этой задаче и есть получение некоторой адекватной модели, по которой затем можно было бы сгенерить ODT. Потом, желательно генерить на-лету, чтобы не напрягать систему, а это опять же непростая под-задача. Фактически, имеем нетривиальную задачу интерпретации HTML/CSS файла, о чем здесь уже написали.

SDE
()
Ответ на: комментарий от arsi

> условия применения стиля гуляючи можно переделать в pcre,
....
> ясен пень, что sed тут не проконает :)

Два противоречащих друг другу довода в одном ответе от одного автора.
Ну да тут уже все более менее ясно, кто есть who.

kmike ★★
()

Решил таки прочитать текст по ссылке :)

Если делать так, как они предполагают, и указанные библиотеки действительно (?) выполняют заявленные функции по преобразованию HTML -> XHTML и CSS2 -> ODF, то почему бы и нет?! Только боюсь, что получится жуткий тормоз. Из-за Perl, из-за XSLT, из-за вылавливания CSS из HTML файлов, да и вообще из-за какой-то несуразной конструкции в целом.

Если же делать по уму, то надо писать свой собственный специализированный интерпретатор для HTML+CSS, а это уже штучная, очень кропотливая и до-о-олгая работа. Зато такой конвертор мог бы получится очень эффективным по скорости и прочим техническим параметрам.

SDE
()
Ответ на: комментарий от r

>Замечу что все же о рендере а не о конвертации - просто таржет девайс не битмап. Термин "конвертация" можно было бы применить, если бы одни стили имели однозначное отображение в другие - подошла бы конвертация. А ее там скорее всего нет - в CSS стили наследуются это раз. Стили могут быть заданы в N метсха - а именно на один и тот же элемент может распространятся стиль парента, у него может быть определено N классов, задан style, плюс может быть конфликтующий параметр тега (width, margin, padding, border, align, etc). Следовательно надо писать нехилый интерпретатор.

Ну, все же под термином "рендеринг" я всегда понимал преобразование метаданных в что-либо, понятное человеческому глазу. А насчет всяких гнусных незакрытых тегов а уж тем более своего интерпретатора я уже писал - достаточно заполучить проверенную библиотеку, которая парсит и HTML и CSS, выдавая на гора древовидную объектную модель. Что касается наследования, то, имея такое дерево, учесть такие штуки не составит труда. Кроме того, результирующий формат наверняка также поддерживает наследование.

Интерпретатор писать на каждый чих - это с ума можно сойти. Велосипедов и так полно.

Хотя не спорю, задача специфичная.

jerry
()
Ответ на: комментарий от kmike

> > условия применения стиля гуляючи можно переделать в pcre,

> ....

> > ясен пень, что sed тут не проконает :) > Два противоречащих друг другу довода в одном ответе от одного автора.

но в разных контекстах. вы бы еще выловили из одного поста слова "да" и "нет" и к ним бы прицепились.

> Ну да тут уже все более менее ясно, кто есть who.

я за вас искренне рад.

arsi ★★★★★
()
Ответ на: комментарий от jerry

>>The devil is in the details, как говорят в Англии.
>А у нас - "глаза боятся, а руки делают" :)
>jerry (*) (04.09.2006 13:44:48)

Да кто бы сомневался! А потом про вас сочиняют поговорики про дурную голову и шаловливые ручки :)

anonymous
()
Ответ на: комментарий от jerry

>Ну, все же под термином "рендеринг" я всегда понимал преобразование метаданных в что-либо, понятное человеческому глазу

Если бы я был человеком придирчивым, я бы сказал, что ODF понятен человеческому глазу не меньше чем JPEG - то бишь без вьевера ни то ни это не росмотришь, но поскольку я человек непридирчивый, то я так не сажу.

r ★★★★★
()

Бюджет - два месяца работы одного специалиста. Что-то не густо. На тестирование и документирование уже денег не остаётся. Так и выйдет в результате, что сделает им кривую поделку студентик-недоучка. Больше никто на такие копеечки не клюнет.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.