Блог

Как сделать так, чтобы время печати под Linux работало? У меня установлен debian wheezy linux, ghostscript, cups, mscorefonts. Но когда я печатаю, я получаю слишком большие значения по сравнению с Windows one — интервал между буквами слишком большой.

Есть способ решить эту проблему?

Печать выполняется из одного и того же Java-апплета и на Win, и на Lin. В Postscript из варианта Lin используются шрифты Times, в postscript из варианта Win используется шрифт TimesNewRomanPSMT. Просто замена названия шрифта изменяет его, но ничего не меняет в выводе.

=================

Debian Wheezy, Debian Squeeze, Ubuntu Natty проверены как linux. Большинство проверок было в Debian Wheezy.

ghostscript: Установлен: 9.02 ~ dfsg-2 sun-java6-jre: Установлен: 6.26-1 cups-pdf printer.

PPD — это PDF.ppd:

 *PCFileName:    "CUPS-PDF.PPD"
*Manufacturer:  "Generic"
*Product:   "(CUPS v1.1)"
*ModelName:     "Generic CUPS-PDF Printer"
*ShortNickName: "Generic CUPS-PDF Printer"
*NickName:      "Generic CUPS-PDF Printer"
*1284DeviceID:  "MFG:Generic;MDL:CUPS-PDF Printer;DES:Generic CUPS-PDF Printer;CLS:PRINTER;CMD:POSTSCRIPT;"
  

Сравнение результатов печати:http://piccy.info/code2/1652248/4b2c3b10f5316f9836496af5501892d1

У меня есть шрифт Times New Roman в системе Linux! PDF для Windows был создан в Linux с помощью Linux ghostscript из исходного кода postscript, созданного на компьютере с Windows.

Например, взгляните в правый верхний угол, где написано 0401060. Код Windows postscript:

 %%IncludeResource: font TimesNewRomanPS-BoldMT
F /F1 0 /256 T /TimesNewRomanPS-BoldMT mF 
/F1S53 F1 [83 0 0 -83 0 0 ] mFS
F1S53 Ji 
4292 333 M (0401060)[42 42 42 42 42 42  0]xS 
N 367 367 M 1192 367 I K 
N 1667 367 M 2492 367 I K 
51282 VM?
  

linux postscript-код:

 10.0 29 F
<303430313036> 37.44 526.0 52.0 S
10.0 29 F
<30> 6.24 541.0 62.0 S
N
  

как вы можете видеть, он выбирает шрифт # 29 размером 10.0. Шрифт # 29 — это
/Раз-Выделенный жирным шрифтом ISOF

и, что хуже всего, он уже записывает две строки — значит, проблема где-то в java<=> cups connector.

================== » Тот же Java-апплет» является приложением интернет-банка iBank2.

«Times» заменяется Ghostscript на Nimbus, а не на TimesNewRoman:

 ./Init/Fontmap.GS:/Times-Roman          /NimbusRomNo9L-Regu ;
./Init/Fontmap.GS:/Times-Italic         /NimbusRomNo9L-ReguItal ;
./Init/Fontmap.GS:/Times-Bold           /NimbusRomNo9L-Medi ;
./Init/Fontmap.GS:/Times-BoldItalic     /NimbusRomNo9L-MediItal ;
./Init/Fontmap.GS:/TimesNewRoman                /TimesNewRomanPSMT      ;
./Init/Fontmap.GS:/TimesNewRoman,Bold           /TimesNewRomanPS-BoldMT     ;
./Init/Fontmap.GS:/TimesNewRoman,Italic         /TimesNewRomanPS-ItalicMT   ;
./Init/Fontmap.GS:/TimesNewRoman,BoldItalic     /TimesNewRomanPS-BoldItalicMT   ;
  

(Кстати, вы вообще используете Ghostscript в Windows, или ваша печать там выполняется через собственный драйвер принтера?)
В Windows я печатаю в собственном драйвере PostScript для файла .ps.

Так что это НЕ проблема Ghostscript как таковая… но, возможно, это происходит из разных версий Java конфигураций в ваших системах Win / Lin. Похоже, что проблема в java при печати, но это не зависит от версии java — у обоих установлена последняя версия java6.

Этот PostScript, скорее всего, генерируется вашим Java-апплетом, и Ghostscript является его потребителем только в процессе печати. Обычно я просто хочу убедиться, что он использует шрифт TimesNewRoman для Times one, а не Nimbus. И мне не удалось это сделать.

Макрос ISOF, созданный при печати, является:

 /ISOF {
     dup findfont dup length 1 add dict begin {
             1 index /FID eq {pop pop} {D} ifelse
     } forall /Encoding ISOLatin1Encoding D
     currentdict end definefont
} BD
  

Вот вырезка начальных файлов и сгенерированный результирующий PDF: http://datacompboy.ru/u/smpl.tar.bz2

Если это так, то скопируйте файл Windows fontfile в Linux.

это уже копия файла Windows. msttcorefonts идентичны одному, распространяемому с Windows.

Поскольку в сгенерированном файле postscript уже 0401060 разделен на две строки, это означает, что Java-апплет при печати обнаружил, что шрифт слишком широкий, и разделил его при генерации… Итак, вопрос — как заменить шрифт Times в системе, чтобы java printing находил TimesNewRoman вместо Nimbus и генерировал правильный вывод?

Из того, что я вижу на скриншоте, ваши различия в печати Win <—> Lin…

• … не возникают в Times <—> TimesNewRomanPSMT различия,
• … но скорее происходит из [иногда] <—> [иногда много] различий в двух выходных данных PostScript

это потребляется каждой очередью принтеров (что в Linux, скорее всего, связано с установкой Ghostscript). (Кстати, вы вообще используете Ghostscript в Windows, или ваша печать там выполняется через собственный драйвер принтера?)

Так что это НЕ проблема Ghostscript как таковая… но это, возможно, происходит из разных версий Java конфигураций в ваших системах Win / Lin.

Тот факт, что в вашем коде Linux PostScript, похоже, используется /Times-Bold (ISOF????) шрифт, выходит за рамки ответственности Ghostscript. Этот PostScript, скорее всего, генерируется вашим Java-апплетом, и Ghostscript является его потребителем только в процессе печати.

Мне кажется, что это зловещее, ISOF о котором вы упомянули, не является частью fontname, а процедурой PostScript, которая должна быть предварительно определена в другом месте файла PostScript и применяется к /Times-Bold шрифту. Вероятно, это процедура, которая перекодирует исходный шрифт в ISOLatin1Encoding…

Вы говорите, что у вас есть доступ к обоим файлам шрифтов (TimesNewRomanPS-BoldMT в Windows и Times-Bold в Linux). Если это так, то скопируйте файл Windows fontfile в Linux. Затем, чтобы проверить визуальные различия между двумя шрифтами, выполните эти две команды для каждого из файлов шрифтов:

 fntsample 
   -f /path/to/Times-fontfile.suffix 
   -o Times-fontfile.suffix.pdf 
   -l 
    > Times-fontfile.suffix.txt
  

и затем

 pdfoutline 
   Times-fontfile.suffix.pdf 
   Times-fontfile.suffix.txt 
   Times-fontfile-sample.pdf
  

Результирующие PDF-файлы, Times-fontfile-sample.pdf, будут представлять собой табличный образец каждого глифа, содержащегося в файлах шрифтов, и они будут сопоставлены с соответствующими разделами кодовых точек Unicode.

Вы можете использовать эти PDF-файлы, чтобы выявить даже минимальные визуальные различия между двумя шрифтами (но я уверен, что ваши различия будут довольно вопиющими).

В случае, если у вас не установлен pdfoutline и fntsample в вашем Debian, просто запустите sudo apt-get install fntsample …

Обновление 2 (с учетом обновленного описания проблемы):

datacompboy теперь предоставил архив, содержащий эти 4 файла:

 -rw-r--r-- datacompboy/datacompboy 37722 2011-06-22 08:54 smpl/linout.ps
-rw-r--r-- datacompboy/datacompboy 15324 2011-06-22 08:54 smpl/linout.pdf
-rw-r--r-- datacompboy/datacompboy 54422 2011-06-22 08:57 smpl/winout.pdf
-rw-r--r-- datacompboy/datacompboy 99099 2011-06-22 08:56 smpl/winout.ps
  

С помощью этих файлов должно быть очень легко определить причину проблемы. Если datacompboy может запустить PS-файл, сгенерированный Windows, в Linux Ghostscript, вот так:

 gs winout.ps
  

и если он отображается нормально (т. Е. Так же, как winout.pdf), то проблем с отображением шрифтов GS нет, но проблема с фактическими различиями файлов в winout / linout.ps. Оттуда должно быть довольно легко продолжить анализ.

К сожалению, прямо сейчас я не могу запустить тест самостоятельно.

Обновление 3:

PDF-файлы datacompboy linout.pdf и winout.pdf имеют одно огромное отличие: в версии Linux шрифт не встроен, в то время как в версии Windows он есть… Следствием этого является то, что любой последующий пользователь linout.pdf будет выдавать довольно произвольные результаты при отображении, печати, преобразовании или обработке этого файла в отношении шрифта.

Итак, вот еще один тест, который я могу придумать. Проверяется, насколько версии шрифтов для Linux, используемые для /Times-Bold (которые заменяются Ghostscript на real /NimbusRomNo9L-Medi ) и /TimesNewRomanPS-BoldMT`, отличаются в своих показателях шрифта.

Создайте три разных PDF-файла с помощью этих командных строк Ghostscript:

a.pdf:

 gs 
 -o a.pdf 
 -sDEVICE=pdfwrite 
 -dPDFSETTINGS=/prepress 
 -c "100 700 moveto 
     /TimesNewRoman,Bold findfont 
     12 scalefont 
     setfont 
     (0401060 0401060 0401060 0401060) show 
     showpage"
  

b.pdf:

 gs 
 -o b.pdf 
 -sDEVICE=pdfwrite 
 -dPDFSETTINGS=/prepress 
 -c "100 700 moveto 
     /TimesNewRomanPS-BoldMT findfont 
     12 scalefont 
     setfont 
     (0401060 0401060 0401060 0401060) show 
     showpage"
  

c.pdf:

 gs 
 -o c.pdf 
 -sDEVICE=pdfwrite 
 -dPDFSETTINGS=/prepress 
 -c "100 700 moveto 
     /Times-Bold findfont 
     12 scalefont 
     setfont 
     (0401060 0401060 0401060 0401060) show 
     showpage"
  

-dPDFSETTINGS=/prepress Параметр должен обеспечивать внедрение шрифта в выходные PDF-файлы. (Это важно, иначе программа просмотра могла бы использовать произвольный заменяющий шрифт для отображения PDF.)

За -c параметром следует небольшой фрагмент PostScript, который предоставляет содержимое для страницы PDF.

Файлы ‘a.pdf’ и ‘b.pdf’ не должны отличаться. Они только проверяют, действительно ли псевдоним шрифта между /TimesNewRoman,Bold и /TimesNewRomanPS-BoldMT работает так, как ожидалось.

Файл ‘c.pdf’ может иметь небольшие отличия по сравнению с a.pdf и b.pdf порядка нескольких пикселей здесь и там, но НЕ в отслеживании тестируемой строки.

Если этот тест проходит так, как предсказывалось, разные файлы шрифтов, карта шрифтов.С GS и самим Ghostscript все в порядке. Тогда проблема заключается только в том, как Java-апплет Linux выдает свои выходные данные (PS или PDF).