Причины создания проекта GNU PDF

мне очень нравится сложившаяся в последнее время тенденция OpenSource-коммунити охватывать нужные и важные области, а не разбираться с очередным берилом и "как запустить HL2 в wine"

зато бурно развивается тенденция велосипедостроительства. Если формат не будет полноценно поддерживаться Adobe Reader (по ссылке еще не ходил, чтобы поподробнее прочесть), нафиг он нужен.

ну вот и до pdf добрались...

а насчет CS2 под wine - может проще заного CS2 написать...а какую там lib можно взятьчтоб уж все не придумывать?

Хм. Из двух новостей про GNU PDF понял следующее:

1) авторы не любят С++, а значит и poppler, и поэтому перепишут все на С
2) еще они хотят добавить в библиотеку функциональность создания PDF
3) на это нужны деньги
4) денег нет

По-моему обе озвученные здесь причины - бред сивой кобылы. По поводу 1 - почему нельзя допилить poppler? По поводу 2 - почему нельзя допилить poppler?

ПреведЪ, лисапедЪ (с) забыл чьё

Лучше бы libpoppler пилили. А относительно создания: PDF Editor чем создаёт их?

Мда... Microsoft в юности. Нет, чтобы доделать poppler, так нет же... Хотя конкуренция дело правильное, но переписывать что-то только из-за того, что обнаружилась фатальная ошибка - приложение написано на не GNU-языке - это уже слишком

Если сделают нормально, то флаг им в руки. Надоело грузить в wine Adobe Proof. чтобы удалить пару рекламных страниц в pdf. Удачи!

Больше велосипедов, хороших и разных

man pdftk

0)Зачастую гораздо проще создать своё с нуля чем допиливать чей-то проект.
При этом, если есть свободные аналоги, то вполне можно черпать оттуда идеи, но для своей реализации.
1)Речь идёт не просто о допиливании, а о реализации _полноценной функциональности_, ибо в существующих на данный момент реализациях всё урезано для обратной совместимости.
Допилить до полноценной функциональности либу, которая была изначально проектирована на ограниченную функциональность также просто, как сделать из сушеной рыбы живую.
2)Существует множество причин, по которым C гораздо лучше C++, например, лучшая стандартизация C и неинтуитивность C++.
Ненадо рассматривать C++ как "улучшенный C". Это _совершенно_ разные языки. Да, часть конструкций справедлива для обоих языков, но только _часть_. Если не знать ВСЕХ особенностей C++ легко наступить на грабли.
В C++, конечно, реализовано ООП, но
a) не в одном C++ оно реализовано. есть, например, и ObjC и Ada
b) ООП не всегда необходимо

Давайте хоть их wiki'у переведем - поможем хоть чем-то, а?

saahriktu, побереги биссер. Только холивар очередной раздуешь.

> Лучше бы libpoppler пилили.

тебе надо, ты и пили. что мешает?

пусть автор xpdf развивает.

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

Респект, не все в лужу дела делают. Радует. А то что С++ нельзя использовать домохозяйкам - это правда, для них Java есть.

Есть два отличных варианта где найти бабла: 1. Продавать кружки и футболки 2. Струсить с Шаттлворта идею дарю :)

не успели проснутся и осознать новость, а говномётная машина уже в действии
стыдно, товарищи, стыдно
читайте как мантру "Значительная часть заложенной в формат PDF функциональности либо используется не полностью, либо вовсе не реализована" добавляя про себя "_всеми_ читалками и редакторами"
очередной велосипед никому не нужен, а вот полная поддержка стандарта ох как нужна
политический вопрос не менее значим, но вторичен по отношению к техническому, ибо целиком и полностью им порождён
удачи разрабам, они делают нужные вещи

Пошлю пацанам баксов триста

Анонимам зачёт. Если не врут.

> 2)Существует множество причин, по которым C гораздо лучше C++, > например, лучшая стандартизация C и неинтуитивность C++. > Ненадо рассматривать C++ как "улучшенный C". Это _совершенно_ > разные языки. Да, часть конструкций справедлива для обоих языков, > но только _часть_. Если не знать ВСЕХ особенностей C++ легко > наступить на грабли. > > В C++, конечно, реализовано ООП, но > a) не в одном C++ оно реализовано. есть, например, и ObjC и Ada > b) ООП не всегда необходимо

Да при чём здесь это? Просто к C-библиотеке просто сделать биндинги для других языков (например, для Perl, Python, PHP, Java и т.д.), а с C++-библиотеке - соответственно, непросто. Это совершенно объективная причина, по которой библиотеки лучше писать на C, а не на C++.

> 2)Существует множество причин, по которым C гораздо лучше C++,
> например, лучшая стандартизация C и неинтуитивность C++.
> Ненадо рассматривать C++ как "улучшенный C". Это _совершенно_
> разные языки. Да, часть конструкций справедлива для обоих языков,
> но только _часть_. Если не знать ВСЕХ особенностей C++ легко
> наступить на грабли.
>
> В C++, конечно, реализовано ООП, но
> a) не в одном C++ оно реализовано. есть, например, и ObjC и Ada
> b) ООП не всегда необходимо

Да при чём здесь это? Просто к C-библиотеке просто сделать биндинги для других языков (например, для Perl, Python, PHP, Java и т.д.), а с C++-библиотеке - соответственно, непросто. Это совершенно объективная причина, по которой библиотеки лучше писать на C, а не на C++.

PS: ещё забыл добавить Java и javascript абсолютно разные языки ;-) обычно ещё и так говорят умные люди.

Ну если вам не нужен контроль типов на уровне ld, то вы правы. Однако value и value() таки разные вещи.

а ещё программы в C++ это не только .cpp, но и .h отсюда ещё куча проблем со сращиванием различных языков. ;-)

> мне очень нравится сложившаяся в последнее время тенденция OpenSource-коммунити охватывать нужные и важные области

Она всегда была, просто раньше не на всё сил хватало. :)

Т.н. libpoppler имеет слишком убогий функционал, до джавовского iText'а ой как далеко. А использовать джавовскую библиотеку, понятно, вообще некошерно и, самое главное, неудобно.

Значит людей хватает=))

Кстати, обратите внимание на то, что добавление функциональности будет осуществляться за счёт реверс-инжиниринга продуктов Adobe - "To help with the application's creation, a member of GNU PDF project is already performing a functional analysis of the latest edition of Acrobat Professional, Adobe's flagship PDF product, in order to reverse-engineer it."

Какой бред, документация на что?

> Давайте хоть их wiki'у переведем - поможем хоть чем-то, а?

могу поучаствовать в этом... но "мой французский - ужасен" :)

> Какой бред, документация на что?

Видимо, такая документация :)

Реверс энжиниринг - это техника позволяющая изучать принципы за счет изучения собранного паровоза а не по чертежам. Не думаешь же ты что они дизассемблироват будут акробат. Это бессмыссленно.

Реверс энжиниринг - это техника позволяющая изучать принципы за счет изучения собранного паровоза а не по чертежам. Не думаешь же ты что они дизассемблироват будут акробат. Это бессмыссленно.

В соседней новости уже сообщили, продублирую и здесь. http://gnupdf.org/index.php?title=Goals_and_Motivations&oldid=1795#Why_ar...

Этот раздел почему-то убрали из вики. Кратко: Ghostscript чересчур большой, для работы с PDF всего этого не нужно. А xpdf и poppler на C++, что неудобно, т.к. почти все остальные программы GNU на C; кроме того C++ хуже переносим и хуже подходит для встраиваемых устройств.

Это доказывает только то, что проектом занимаются клинические идиоты.

FYI написал внутреннюю библиотеку для экспорта PDF в Scribus просто изучив спеки. Причём PDF генерится в итоге охрененно точный.

> ... что добавление функциональности будет осуществляться за счёт реверс-инжиниринга ...

Читаем внимательно:
a functional analysis ... in order to reverse-engineer it.

У меня ощущение, что не код реверсить будут, а выискивать интересующую функциональность и переписывать ее в свой проект.

> библиотеку для экспорта PDF в Scribus просто изучив спеки. Причём PDF генерится в итоге охрененно точный.
Проекту Scribus это сделать не сложно, т.к. у них есть определенный функционал который нужно было формализовать в другом формате.
Им не требовалось поддержки _всех_ возможностей PDF, а только тех, что умеет Scribus.
Таким образом задача сильно упростилась.

>Это совершенно объективная причина, по которой библиотеки лучше писать на C, а не на C++

Интерфейс "наружу" библиотеки никак не связан с языком программирования, на котором эта библиотека написана (если явно не ставить обратную цель)

> Интерфейс "наружу" библиотеки никак не связан с языком программирования, на котором эта библиотека написана (если явно не ставить обратную цель)

онанизмус, это из той же оперы, что и "всё можно написать на машине Тьюринга" ;)

> зато бурно развивается тенденция велосипедостроительства. Если формат не будет полноценно поддерживаться Adobe Reader [...], нафиг он нужен.

Ну, под виндой есть несколько альтернативных программ для просмотра PDF, так что это не проблема. Да и какое мне дело до Adobe? Новые возможности формата смогут использовать хотя бы по эту сторону баррикад, например, в презентациях или описаниях, что меня вполне устроит. Да и идеология GNU не значит, что их библиотеки будут ориентированы только на Linux, под виндой тоже будет, я не сомневаюсь.

Велосипеды от GNU самые велосипедистые велосипеды в мире

так речь-то не о просмотре, а о нововведениях в формате или разработке нового. Стандарт - чтобы нормально открывался в Adobe Reader, остальное - пионерство.

Опять Hurd делают, я смотрю...

>кроме того C++ хуже переносим и хуже подходит для встраиваемых устройств.

ARM? Ну тогда я читаю pdf с наладонника во сне.

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

Ну и не флейма ради, хорошо, что еще есть люди, которые пишут на С :) Ведь для низкоуровневой библиотеки С++ нафиг не нужен...

>Им не требовалось поддержки _всех_ возможностей PDF, а только тех, что умеет Scribus.

Он имеет ввиду что спека нам весьма вменяемая. И она такая и есть. Просто занимает под 1000 страниц.

> Им не требовалось поддержки _всех_ возможностей PDF, а только тех, что умеет Scribus.

На самом деле, Scribus делает несколько больше, чем Вы, вероятно, предполагаете. Например, в нем можно делать электронные формуляры и презентации (да-да, с эффектами перехода, предусмотренными в PDF).

>о нововведениях в формате или разработке нового

Жесткая абстиненция? Про разработку НОВОГО формата ни слова нет :)

> Стандарт - чтобы нормально открывался в Adobe Reader, остальное - пионерство.

PDF is an open standard, and is now being prepared for submission as an ISO standard. (ц)

Я не видел Adobe Reader уже несколько лет, как и многие здесь присутствующие. Если эдаб не в силах поддерживать стандарт - это их проблемы, так как есть полнофункциональные альтернативы.