> Да, ну? :))) Нет проблем с кодировками говорите? Если не сталкивались с этими проблемами это не означает их нет. doc - хитрый документ.

Я бы даже сказал хитрожопый!

>Только есть модули взаимодействия с опенофисом для питона, для жабы (ну само собой) и для других языков. А под перл - нет.

http://search.cpan.org/~jmgdoc/OpenOffice-OODoc/

Это особенность языка такая наверное. Вот например, пресловутая строчка на перле - это фича или бага?

Ну.. наверноне я не совсем прав. Я делаю вебморду к одной офисной системе, морда занимается управлением документами, графиком и генерацией отчетов. Вполне себе средненькой проектик. И с перлом в этой области одни проблемы.

Косяки с utf8, косяки между DBI и постгресом (опять же из-за utf8). Потом оказалось что ничего подходящего в cpan нет ни для диаграмм ганта, ни для работы с разными форматами документов ни для генерации отчетов (промолчим про ту-же жабку)... и много много других сложностей и вопросов. Правда они все уже преодолены ; )

А модулей в cpan много, вот только их качество и полезность мало кто оценивает. Хотя есть очень хорошие и заслуженые.. )

Я тогда скажу по другому - для работы с офисными задачами перл нынче не очень подходит.

Угу, когда намаетесь с проблемой преобразования форматов текстовых файлов и генерацией онных, тогда по другому заговорите. Уж лучше этот бред, чем черт знает что. Прочитайте про uno на сайте опенофиса, и вы поймете, что это хорошая и правильная штучка.

А по поводу кодировок, видимо вы не сталкивались с этой проблемой. .doc + utf8 это ещё та гремучая смесь... Я уже промолчу про то, что нет распространенных коносльных утилит и перловых модулей, что бы переделать ртф.док в хтмл без проблем с русским языком (((

Это все хорошо,

Но как с помошью этого модуля файл в формате rtf преобразовать в doc и html? А взять док и вытащить из него все картинки? А динамически сгенерить таблицу и сохранить её как пдф? Фигвам. Я не нашел удобных инструментов для этого для перла.

А опен офис все это умеет (и даже больше), и биндинги к uno для питона с++ и явы позволяют делать с помощью этих языков все что может делать опенофис, а то что вы показали лишь позволяет напрямую работать с внутреностями родных файлов опен офиса, которые кажется заархивироваый xml.

А для перла боюсь никто не осилит реализацию биндинга к uno ;(

зы, я вовсе не хочу сказать что перл плох, наоборот, прекрасный язык и я его люблю ; )

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

Нам есть над чем работать ; )

> А для перла боюсь никто не осилит реализацию биндинга к uno ;(

если это нормальная С библиотека, то при помощи XS это сделать можно на раз

"Дурак, в .Net нет языков - можно писать на чём угодно - perl.net что такое по твоему ?"

Отличный образец скудоумия... Учитесь красноглазые!

Возразить самому себе в одном предложении! Поздравляю Голодранец...

У ты мой маленький Элио...

Ну не плачь не плачь... И тебя тоже вылечат...

>Ну.. наверноне я не совсем прав. Я делаю вебморду к одной офисной системе, морда занимается управлением документами, графиком и генерацией отчетов. Вполне себе средненькой проектик. И с перлом в этой области одни проблемы.

> Косяки с utf8, косяки между DBI и постгресом (опять же из-за utf8). Потом оказалось что ничего подходящего в cpan нет ни для диаграмм ганта, ни для работы с разными форматами документов ни для генерации отчетов (промолчим про ту-же жабку)... и много много других сложностей и вопросов. Правда они все уже преодолены ; )

Странно. Я делаю примерно то же самое. Беру данные из PostgreSQL (в UTF-8), генерирую отчёт в формате Open Document и высылаю через CGI пользователю.

И наоборот. Выдаю пользователю электронную таблицу (тоже Open Document), в которую он вписывает данные (текст и числа) и возвращает мне в HTML форме на сервер, где данные сбрасываются на PostgreSQL.

И всё на Perlе (веб-интерфейс на PHP). И как-то я не заметил косяков. Может, передозировал RTFM?

> А взять док и вытащить из него все картинки?

Есть модуль Archive::Chm. Форматы CHM и DOC в плане хранения картинок очень похожи.

> А динамически сгенерить таблицу и сохранить её как пдф?

Нужно сгенерить LaTeX-файл (текстовый) и обработать pdflatex'ом.

> как с помошью этого модуля файл в формате rtf преобразовать в doc

А зачем документы в doc преобразовывать? С этой задачей не каждый MS Word справится. Результаты конверсии в doc с помощью OpenOffice тоже временами не предсказуемы. И вообще, поскольку никто не знает, как должен выглядеть документ формата doc, задача конверсии в этот формат не разрешима. И если кто-то говорит, что умеет это сделать, то он просто шарлатан.

А вообще присмотрись модую Win32 --- по-моему там что-то есть про офисные форматы.

> динамически сгенерить таблицу и сохранить её как пдф?

http://search.cpan.org/~areibens/PDF-API2-0.51/lib/PDF/API2.pm

> лишь позволяет напрямую работать с внутреностями родных файлов опен офиса, которые кажется заархивироваый xml.

Не только работать, но и генерировать новые документы. И не только формата OpenOffice, но и Open Document (ISO/IEC 26300)

> А для перла боюсь никто не осилит реализацию биндинга к uno ;(

А может, кроме тебя это никому не нужно? Если так, то тебе придётся самому эту реализацию осилить. Или имелось ввиду, что такая реализация в принципе невозможна?

Видимо так, уважаемый анонимус ; ) значит я первая ласточка новой эпохи ; ) А сам я такое полюбому не осилю.. ни времени ни знаний в достаточном количестве нет...

Кстати какие-то ребята уже делают такое, только они начали в феврале, на сайте даже ничего нет кроме названия, ждемс...

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

Не поверишь ; ) я умею "это" делать, правда в рамках того что может позволить опен офис. ; ) к перлу его таки можно прикрутить, но весьма ограничено..

а Win32 под Win32 только и работает.. (. По поводу пдф.. это офигительный геморой под каждый формат файла юзать специфический модуль, причем каждый из которых со своими офигительными заморочками и проблемами с юникодом и кирилицей. ; ( Собсна поэтому и был прикручен опофис, заморочек и в нем полно, но они одинаковы для всего ; )

Я бы OpenDocument c удовольствием бы юзал, только он пока не распространен. С ним то все открыто и понятно..

А вот мс офисовские форматы, в которых почти весь документооборот идет в фирмах... это пипец. Возможность хоть как-то прикрутить опофис весьма облегчила жизнь ; )

А по поводу ютф, там какие-то глюки с DBI были, вылечилось обновлением на новую версию. Кстати, не подскажешь, до сих пор не могу подсчитать кол-во символов в строках полученых из постгреса. Perl почему-то упорно не выставляет utf флаг для этих строк, и поэтому считает их размер по length() неправильно. Что сделать - ума не приложу.

Боюсь, что там офигительно ненормальная ява и куча xml ; )

А по производительности Perl обходит PHP? При интенсивной работе с БД.... И грамотно написанном коде?

> Кстати, не подскажешь, до сих пор не могу подсчитать кол-во символов в строках полученых из постгреса

use utf8; ... utf8::decode $ТоЧтоИзPostgreSQL; my $l=length($ТоЧтоИзPostgreSQL);

А зачем, если не секрет, считать кол-во символов в офисных документах?

Можно не отвечать, если это становится частью

> личной переписки с участниками дискуссии, не интересной остальным ее участникам

> Косяки с utf8, косяки между DBI и постгресом (опять же из-за utf8)

видать Вы писали программы предварительно не подумавши

я писал на Perl/Tk кроссплатформенных клиентов для Oracle & MySQL, в винте весь интерфейс cp1251, в линуксе - utf8. Косяков нет ВООБЩЕ. Вся разница между платформами - заменить в конфиге 1 на 0.

Просто ЗАРАНЕЕ надо об этом подумать.

> А по производительности Perl обходит PHP? При интенсивной работе с БД.... И грамотно написанном коде?

на MySQL скорость должна быть равной, по крайней мере запросы обе делают через mysql_real_query(). В Perl'е идет практически прямой вызов от execute(). Если в php не напортичили (клиета php писали в mysql, поэтому не должно), то скорость будет такой же. Теряться скорость может на обработке уже полученных данных. И вот если одним запросом из базы будет получаться очень большой массив данных (а не построчная обработка), то php может слить.

> use utf8; ... utf8::decode $ТоЧтоИзPostgreSQL; my $l=length($ТоЧтоИзPostgreSQL);

а зачем use utf8 ?

для перекодирования в/из uft8 это не нужно. 
use Encode;
...
decode('cp1251', $ТоЧтоИзPostgreSQL);
или
encode('cp1251', $ТоЧтоИзPostgreSQL);
в зависимости от того, что вам надо.

Ну, я с utf впервой борюсь. ; ) вроде успешно, просто думал что будет глаже.

В издательском бизнессе часто практикуют оплату за килобайты текста или количество печатных знаков. Прямо как в некоторых програмисстких конторах ; ) т.е. автору говорят что нужно накалякать статейку на 10 000 знаков про путена.. ; ) и стоить это будет по стокато рублей за тысчу буков. Автор идет и калякает.. ; )

use utf8 вроде бы по документации отменили в последних версиях перла. Типо оно теперь само автоматом должно определять (выставлять флаг) юникодная строка или нет, только что-то не всегда верно определяет ;(

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

Да, и у меня почему-то encode - decode в упор не хотят работать. Пишу как у тебя написано... все равно остается utf.

ubuntu dapper - last/все модули из апта, самосбора нет.

> В издательском бизнессе часто практикуют оплату за килобайты текста или количество печатных знаков. Прямо как в некоторых програмисстких конторах ; ) т.е. автору говорят что нужно накалякать статейку на 10 000 знаков про путена.. ; ) и стоить это будет по стокато рублей за тысчу буков. Автор идет и калякает.. ; )

А зачем автор? Нельзя, что ли, скрипт на Перле написать, который бы статейку на эту тему накалякал? ;-)

У меня одна и та же строка до вызова ее обработки сторонними модулями была utf. После обработки уже нет. :) И наооборот тоже бывало. Это кстати об отлаженности perl. сам перл достаточно отлажен. пока дело не касается кодировок и огромного множества модуелей.

>А по производительности Perl обходит PHP? При интенсивной работе с БД.... И грамотно написанном коде?

При "интенсивной работе с БД" узкое место БД, т.е. хоть на java. По скорости perl и пых-пых, примерно, одинаково работают.

>По скорости perl и пых-пых, примерно, одинаково работают.

О дааа... http://www.softportal.com/hotarticles/241

Подведем этоги. На Перле можно писать все что угодно.

#!/usr/bin/perl
print ("Perl rulezzz...\n");

:)

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

> Да, и у меня почему-то encode - decode в упор не хотят работать. Пишу как у тебя написано... все равно остается utf.

Советую прочитать "man Encode" полностью, там всё описано, объяснено как perl с кодировками в данных работает. Никакой особой магии нет, просто понять надо. Я не спорю, иногда лень разбираться, но раз тебе надо, ты уж почитай. :)