Re: OpenOffice
On Sun, 24 Feb 2002, aen wrote: Hi, Anton Petrusevich wrote: On Sun, Feb 24, 2002 at 03:34:55AM +0300, aen wrote: ttf надо установить в X и в OOo. Убедитесь, что другого Arial у Вас в системе нет, и что в каталоге с ttf есть ссылка на encodings.dir , а в fonts.dir описаны шрифты в microsoft-cp1251 Кривь какая. Всю эту бодягу вообще планируется фиксить? Или как обычно вам надо -- вы и делайте? Как обычно -- у кого? Подробнее, пожалуйста. Почему шрифт надо ставить в два места? Свободные ttf включены в нашу сборку OOo и их не надо устанавливать дважды. Если они Вас устраивают -- отлично, если нет -- ждите, работа над ними идет, хотите -- присоединяйтесь. Если хотите работать с ttf от MS -- получайте букет проблем (легко разрешимых: впрочем, особенно если их брать с сайта MS, а не из дистрибутива Win). Проблемы эти связаны с лицензией MS и не зависят от разработчиков OOo и Debian. Проблемы конечно только лицензионного плана? Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. А можно поподробнее про парсер afm от adobe? Почему они неприемлимы (с технической точки зрения)? Просто парсер от adobe не может быть неправ - все что он делает - строит по afm С-шные структуры, без каких-либо интерпретаций имен глифов и encoding. IMHO в укор ему можно поставить только то, что он не делает что-то кроме вышеописанного. Best regards, -Vlad
Re: OpenOffice
Vlad Harchev wrote: Свободные ttf включены в нашу сборку OOo и их не надо устанавливать дважды. Если они Вас устраивают -- отлично, если нет -- ждите, работа над ними идет, хотите -- присоединяйтесь. Если хотите работать с ttf от MS -- получайте букет проблем (легко разрешимых: впрочем, особенно если их брать с сайта MS, а не из дистрибутива Win). Проблемы эти связаны с лицензией MS и не зависят от разработчиков OOo и Debian. Проблемы конечно только лицензионного плана? Да. Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. А можно поподробнее про парсер afm от adobe? Почему они неприемлимы (с технической точки зрения)? Просто парсер от adobe не может быть неправ - все что он делает - строит по afm С-шные структуры, без каких-либо интерпретаций имен глифов и encoding. IMHO в укор ему можно поставить только то, что он не делает что-то кроме вышеописанного. Парсер не виноват, конечно. Виноваты программисты, которые берут из него вектор кодировки, не имея ни малейшего понятия о Unicode ps-шрифтах (очень-очень многие считают, что таких просто нет). Если бы в структуру добавить unicode каждого глифа, то все были бы счастливы. Rgrds, AEN
Re: OpenOffice
aen wrote: Vlad Harchev wrote: Свободные ttf включены в нашу сборку OOo и их не надо устанавливать дважды. Если они Вас устраивают -- отлично, если нет -- ждите, работа над ними идет, хотите -- присоединяйтесь. Если хотите работать с ttf от MS -- получайте букет проблем (легко разрешимых: впрочем, особенно если их брать с сайта MS, а не из дистрибутива Win). Проблемы эти связаны с лицензией MS и не зависят от разработчиков OOo и Debian. Проблемы конечно только лицензионного плана? Да. Не понял сразу Ваш вопрос, отвечу подробнее. Корень проблемы -- лицензия, но суть ее в том, что в системе появляются заменители MS ttf с теми же именами. Они якобы необходимы для документов, импортиремых из MS Office. Пример -- Abi, другой пример, правда из RH, -- варезные (это в RH!) шрифты Peter Soos из пакета ISO8859-2-fonts. Конечно, некоторые умные офисы, даже если не найдут Times New Roman, подставляют Times, но тут-то на его месте оказвается алиас на NimbusRomanNo9, который в стандартной поставке не содержит кириллических глифов. А даже если содержит, то большинство программ будут рендерить его с метриками от Adobe. В общем, если у кого-то есть знакомые дизайнеры шрифтов -- просите их поработать над шрифтами URW/Вали Филиппова. Я уже нашел двоих, но работы много. Проблема в том, что рендеринг Type1 и, отчасти, ttf в XFree, Win и MacOS сильно различается и то, что хорошо смотрится в Win, в Linux будет криво (и наоборот). Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. А можно поподробнее про парсер afm от adobe? Почему они неприемлимы (с технической точки зрения)? Просто парсер от adobe не может быть неправ - все что он делает - строит по afm С-шные структуры, без каких-либо интерпретаций имен глифов и encoding. IMHO в укор ему можно поставить только то, что он не делает что-то кроме вышеописанного. Парсер не виноват, конечно. Виноваты программисты, которые берут из него вектор кодировки, не имея ни малейшего понятия о Unicode ps-шрифтах (очень-очень многие считают, что таких просто нет). Если бы в структуру добавить unicode каждого глифа, то все были бы счастливы. Добавлю и здесь. Когда я делал патч для печати i18n в Mozilla, то времени на чтение 900-страничной книги от Adobe не было и пришлось пойти своим путем. Вместо обычной утомительной генерации многих (в общем случае) векторов кодировки (по сути, собственных шрифтов внутри ps-файла), что очень неприятно для текста, содержащего много разных Unicode-глифов, я воспользовался функцией вывода глифа по его имени (glyphshow). Почему-то ей никто не пользуется, а, между тем, выходной ps получается исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Может быть, это будет полезно тому, кто занимается интернационализацией печати. Rgrds, AEN Rgrds, AEN
Re: OpenOffice
On Sun, 24 Feb 2002, aen wrote: Если договориться о том, что используются только свободные шрифты, то приведение шрифтовой системы OOo в порядок не составит для нас никакого труда. Однако, подавляющее большиство пользователей использует шрифты MS/Monotype. В целом, шрифтовая система Debian, как и всех других дистрибутивов, крайне крива. Улучшить ее можно только путем создания свободных Unicode ttf и отказа от TypeX в _базовой_ системе. Дело не в том, что ps-шрифты концептуально плохи (они как раз хороши!), а в том, базовые afm и их парсеры от Adobe, используемые повсеместно, абсолютно неприемлемы не только для Unicode ps-шрифтов, но даже для шрифтов URW, которые являются стандартом de facto в свободных системах. Легче убить, чем все переделать. А можно поподробнее про парсер afm от adobe? Почему они неприемлимы (с технической точки зрения)? Просто парсер от adobe не может быть неправ - все что он делает - строит по afm С-шные структуры, без каких-либо интерпретаций имен глифов и encoding. IMHO в укор ему можно поставить только то, что он не делает что-то кроме вышеописанного. Парсер не виноват, конечно. Виноваты программисты, которые берут из него вектор кодировки, не имея ни малейшего понятия о Unicode ps-шрифтах (очень-очень многие считают, что таких просто нет). Если бы в структуру добавить unicode каждого глифа, то все были бы счастливы. Согласен.. Надеюсь, что с вводом евро в европе скорость исправления таких программ станет намного выше.. Best regards, -Vlad
Re: random ip substitution
On Sun, 24 Feb 2002, Ingvarr Zhmakin wrote: Если или как, то кто мне мешает X-Forwarderd-For: случайный-адрес-из 10/8 поставить? Так, а эта фишка на каком этапе возникает? В самом прокси или при стуке на него? Не важно как она возникает. Важно как ее видит MTC-овский сайт. А он видит ее как обычный HTTP-заголовок. Ты его можень руками поставить хоть в LWP, хоть в wget-е
Re: OpenOffice
On Sun, 24 Feb 2002, aen wrote: Когда я делал патч для печати i18n в Mozilla, то времени на чтение 900-страничной книги от Adobe не было и пришлось пойти своим путем. Вместо обычной утомительной генерации многих (в общем случае) векторов кодировки (по сути, собственных шрифтов внутри ps-файла), что очень неприятно для текста, содержащего много разных Unicode-глифов, я воспользовался функцией вывода глифа по его имени (glyphshow). Почему-то ей никто не пользуется, а, между тем, выходной ps получается Наверное потому что (некоторый кусок текста) show превращается в примерно десять раз более длинную констркуцию, даже если написать функцию типа glypharrayshow которая бы употреблялась не большее число раз чем show в нормальном ПС. В книге Thinking In Postscript упоминалось что для многобайтовых кодировок используется какой-то метод шестнадцатиричного кодирования. Но, видимо, полное его описание есть только в 900 страничной книжке от Adobe. исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Размер файла в реальной жизни иногда тоже бывает значим. Может быть, это будет полезно тому, кто занимается интернационализацией печати. Я давно думаю над аналогичной констркуцией для Tk. Только я хотел системную кодировку (если она 8-битная) использовать как есть, считая что чисто статистсически большая часть букв на данном конкретном компьютере в нее попадет. А что не попадет - то по явным именам глифов.
Re: OpenOffice
Victor B. Wagner wrote: On Sun, 24 Feb 2002, aen wrote: Когда я делал патч для печати i18n в Mozilla, то времени на чтение 900-страничной книги от Adobe не было и пришлось пойти своим путем. Вместо обычной утомительной генерации многих (в общем случае) векторов кодировки (по сути, собственных шрифтов внутри ps-файла), что очень неприятно для текста, содержащего много разных Unicode-глифов, я воспользовался функцией вывода глифа по его имени (glyphshow). Почему-то ей никто не пользуется, а, между тем, выходной ps получается Наверное потому что (некоторый кусок текста) show превращается в примерно десять раз более длинную констркуцию, даже если написать функцию типа glypharrayshow которая бы употреблялась не большее число раз чем show в нормальном ПС. В том то и дело, что приведенная Вами конструкция используется повсеместно. И для меня не очевидно, что (некоторый кусок текста) glyphshow развернется в конструкцию длиннее В книге Thinking In Postscript упоминалось что для многобайтовых кодировок используется какой-то метод шестнадцатиричного кодирования. Но, видимо, полное его описание есть только в 900 страничной книжке от Adobe. Боюсь, что нет и в ней. Разве только в виде ссылок на другие документы. Во всяком случае, при диагональном просмотре я не нашел. исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Размер файла в реальной жизни иногда тоже бывает значим. Размер можно сильно уменьшить, если посдставлять имена глифов при генерации ps, а не в самой ps-программе. Может быть, это будет полезно тому, кто занимается интернационализацией печати. Я давно думаю над аналогичной констркуцией для Tk. Только я хотел системную кодировку (если она 8-битная) использовать как есть, считая что чисто статистсически большая часть букв на данном конкретном компьютере в нее попадет. А что не попадет - то по явным именам глифов. Проблем здесь никаких. Вряд ли стоит изучать мой патч, но в ps-программах из gs Вы легко найдете примеры использования glyphshow. Rgrds, AEN
Re: OpenOffice
On Sun, 24 Feb 2002, Aleksey Novodvorsky wrote: Наверное потому что (некоторый кусок текста) show превращается в примерно десять раз более длинную констркуцию, даже если написать функцию типа glypharrayshow которая бы употреблялась не большее число раз чем show в нормальном ПС. В том то и дело, что приведенная Вами конструкция используется повсеместно. И для меня не очевидно, что (некоторый кусок текста) glyphshow развернется в конструкцию длиннее Для меня очевидно, что имя глифа для кириллицы занимает в файле примерно в 10 раз больше места, чем один символ. И неочевидно как это сократить. А начавши рассматривать PS-программы от gs я наткнулся там на вот такой комментарий: % We have to define BuildChar rather than BuildGlyph: % there is no PDF equivalent of glyphshow, and we need % the character code to access the Widths. Может для печати из Мозиллы это и некритично, а вот для генерации PS вообще пригодность для дистилляции критична крайне. исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Кстати, я тут подумал, что интересным подходом к генерации PS является тот, что применен в html2ps. Этот скрипт не читает afm-ок вообще. Тем не менее параграфы выравниваются, переносы делаются и буковки друг на друга не наползают. Размер файла в реальной жизни иногда тоже бывает значим. Размер можно сильно уменьшить, если посдставлять имена глифов при генерации ps, а не в самой ps-программе. То есть с точностью до наоборот? Из общих соображений чем больше работы мы делаем до генерации PS, и чем меньше - внутри PS-интерпретатора, тем больше файл. Вообще, а не возродить ли список cyrfonts? Похоже пошла вторая волна идеологически правильной кириллизации. Первая была - создание хоть каких-нибудь свобоных кириллических шрифтов. Теперь такие шрифты есть - и URW, и sharatype, и cm-super. Дело за малым - научить все заслуживающие внимания программы корректно с ними работать.
Re: OpenOffice
Victor B. Wagner wrote: On Sun, 24 Feb 2002, Aleksey Novodvorsky wrote: В том то и дело, что приведенная Вами конструкция используется повсеместно. И для меня не очевидно, что (некоторый кусок текста) glyphshow развернется в конструкцию длиннее Для меня очевидно, что имя глифа для кириллицы занимает в файле примерно в 10 раз больше места, чем один символ. Неочевидно :-) То есть, если у Вас один вектор кодировки, соответствующий реальной восьмибитной кодировке -- да. Но обычный случай -- несколько векторов, в которых глифы идут в порядке появления, а тогда в () попадет не символ, а его номер. Конечно, остается еще afii , но это уже не на порядок больше. Если же учесть необходимость хранить сами векторы с именами глифов, то на небольшом тексте получаем выигрыш для glyphshow. И неочевидно как это сократить. А начавши рассматривать PS-программы от gs я наткнулся там на вот такой комментарий: % We have to define BuildChar rather than BuildGlyph: % there is no PDF equivalent of glyphshow, and we need % the character code to access the Widths. Может для печати из Мозиллы это и некритично, а вот для генерации PS вообще пригодность для дистилляции критична крайне. Надо смотреть. Часть фразы полсе запятой выглядит крайне сомнительно, похоже что это именно то, о чем мы говорили здесь в связи с парсером. Для access to the Widths совершенно не обязателен character code. Возможно, что имеющиеся проблемы с генерацией pdf связаны с этим заблуждением. исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Кстати, я тут подумал, что интересным подходом к генерации PS является тот, что применен в html2ps. Этот скрипт не читает afm-ок вообще. Тем не менее параграфы выравниваются, переносы делаются и буковки друг на друга не наползают. Сейчас нет под рукой. Вообще говоря, отдельный afm нужен только в том случае, если в системе нет pfb(a). Да и вывод глифов одной фразы (то есть фрагмента, выводимого относительно некоей точки) всегда будет выглядеть корректно, без наползания (но, возможно, с выходом за границу листа). Размер файла в реальной жизни иногда тоже бывает значим. Размер можно сильно уменьшить, если посдставлять имена глифов при генерации ps, а не в самой ps-программе. То есть с точностью до наоборот? Из общих соображений чем больше работы мы делаем до генерации PS, и чем меньше - внутри PS-интерпретатора, тем больше файл. Большой файл -- да. Маленький -- нет, так как в ps надо включать векторы или таблицу glyphs-unicode. Вообще, а не возродить ли список cyrfonts? Похоже пошла вторая волна идеологически правильной кириллизации. Первая была - создание хоть каких-нибудь свобоных кириллических шрифтов. Теперь такие шрифты есть - и URW, и sharatype, и cm-super. Дело за малым - научить все заслуживающие внимания программы корректно с ними работать. Мысль хорошая, но прорыв здесь будет если и только если удастся те же свободные URW с кириллицей поселить в mainstream. В Rawhide они уже есть. Что же касается gs-fonts, то Raph тормозит процесс без объяснения причин. Даже Столлмен не может его продавить. Rgrds, AEN
Re: OpenOffice
On Sun, 24 Feb 2002, Victor B. Wagner wrote: On Sun, 24 Feb 2002, Aleksey Novodvorsky wrote: Наверное потому что (некоторый кусок текста) show превращается в примерно десять раз более длинную констркуцию, даже если написать функцию типа glypharrayshow которая бы употреблялась не большее число раз чем show в нормальном ПС. В том то и дело, что приведенная Вами конструкция используется повсеместно. И для меня не очевидно, что (некоторый кусок текста) glyphshow развернется в конструкцию длиннее Для меня очевидно, что имя глифа для кириллицы занимает в файле примерно в 10 раз больше места, чем один символ. И неочевидно как это сократить. Как генерить PS при многобайтовых кодировках без использования glyphshow можно посмотреть на PS, который генерит gnome-print. Получается очень компактно. А начавши рассматривать PS-программы от gs я наткнулся там на вот такой комментарий: % We have to define BuildChar rather than BuildGlyph: % there is no PDF equivalent of glyphshow, and we need % the character code to access the Widths. Может для печати из Мозиллы это и некритично, а вот для генерации PS вообще пригодность для дистилляции критична крайне. Наверно это относится к коду ps2pdf из пакета ghostscript - distiller на порядки поинтеллектуальней и он понимает имена глифов (рисуемых через glyphshow) если они стандартые. исключительно примитивен и легко читаем. Скорее всего, это увеличивает время интрепретации, но в реальной жизни я этого не наблюдал. Кстати, я тут подумал, что интересным подходом к генерации PS является тот, что применен в html2ps. Этот скрипт не читает afm-ок вообще. Тем не менее параграфы выравниваются, переносы делаются и буковки друг на друга не наползают. Ну, это не-wysiwyg режим - приложение-генератор не узнает сколько листов займет текст, возникают проблемы с колонтитулами. нумерацией страний, text reflowing если текст длиннее 1 страницы. Для CJK и LTR языков и языков для которых требуется shape combining это просто не применимо. Размер файла в реальной жизни иногда тоже бывает значим. Размер можно сильно уменьшить, если посдставлять имена глифов при генерации ps, а не в самой ps-программе. То есть с точностью до наоборот? Из общих соображений чем больше работы мы делаем до генерации PS, и чем меньше - внутри PS-интерпретатора, тем больше файл. Вообще, а не возродить ли список cyrfonts? Похоже пошла вторая волна идеологически правильной кириллизации. Первая была - создание хоть каких-нибудь свобоных кириллических шрифтов. Теперь такие шрифты есть - и URW, и sharatype, и cm-super. Дело за малым - научить все заслуживающие внимания программы корректно с ними работать. Best regards, -Vlad
SQL: стиль даты
Подскажите пожалуйста! У postgresql есть команда set datestyle to 'X*' где X* - один из стилей вывода даты. Хочется знать насколько переносим этот способ м-у различными db? Подозреваю, что непереносимо. А что по этому поводу говорит стандарт? То есть я хочу узнать, есть ли способ универсальный для всех баз данных для установки выходного(или входного) формата даты?
Re: random ip substitution
On Sat, Feb 23, 2002 at 11:43:35PM +0300, Victor B. Wagner wrote: Хитрость в том, что вебмастера в MTC - чайники. Как человек, который с ними общался, могу сказать, что они не чайники ни разу :) -- Regards, Wartan. echo Your stdio isn't very std. -- Larry Wall in Configure from the perl distribution
Re: random ip substitution
On Sun, Feb 24, 2002 at 11:56:46PM +0300, Wartan Hachaturow wrote: Хитрость в том, что вебмастера в MTC - чайники. Как человек, который с ними общался, могу сказать, что они не чайники ни разу :) они просто очень ленивые :) Когда я нарвался на ситуацию блокировки ip после некоторого количества обращений, так просто сделал переборку проксей. Прокси взял со spylog. -- Anton Petrusevich
