Вопрос

Как сделать время, работая для печати под Linux? У меня установлены Debian Wheezy Linux, Ghostscript, Cups, MscoreFonts. Но когда я печатаю, я получаю слишком широкое время, по сравнению с Windows One - расстояние между буквами слишком широкое.

Любой способ решить эту проблему?

Печать сделана из того же Java -апплета и на победе и на Лин. PostScript от Lin Variant Использование Times Fonts, PostScript от Win Variant использует шрифт TimesNewRomsPMT. Просто замена имени шрифта меняет его, но ничего не меняет в выводе.

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

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

Ghostscript: установлен: 9.02 ~ DFSG-2 Sun-Java6-Jre: установлен: 6.26-1 Printer Cups-PDF.

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;"

Результат печати Coparsion: http://piccy.info/code2/1652248/4b2c3b10f5316f9836496af5501892d1/

У меня есть время новый римский шрифт в системе 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 ISOF

И, что хуже всего, это уже пишет две строки - так что проблема где -то в Java <=> Cups Connector.

================= "Тот же Java Applet"-это приложение для интернет-банка IBank2.

«Времена» заменяется 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 Applet, и 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 Applet находится во время печати, обнаружив, что шрифт слишком широкий и разделен при генерации ... так что вопрос - как заменить шрифт Times в систему, так что Java Печать найдет Timesnewroman вместо Nimbus и генерирует правильный вывод?

Это было полезно?

Решение

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

  • ...делать НЕТ происходить в Время <-> timesnewromanpsmt различия,
  • ... но скорее приходите из Иногда] <--> [Иногда сочетается Различия в 2 выводах PostScript

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

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

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

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

Вы говорите, что у вас есть доступ к обоим файлам шрифтов (Timesnewromanps-Boldmt В окнах и Времена на 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 (S), Times-Fontfile-Sample.pdf, будет представлять табличный образец каждого глифа, содержащийся в фонфилях, и они будут сопоставлены с соответствующими разделами Codepoints 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 может запустить сгенерированный Windows-файл PS на Linux Ghostscript, например:

gs winout.ps

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

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


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

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

Итак, вот еще один тест, о котором я могу подумать. Он проверяет, сколько версии шрифтов Linux используются для /Times-Bold (который заменяется GhostScript на настоящий /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 Параметр должен обеспечить соблюдение шрифта, встраивающегося в выходные pdfs. (Это важно, в противном случае зритель может использовать произвольный шрифт для отображения PDF.)

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

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

Файл 'c.pdf' может показать небольшие различия по сравнению с A.pdf а также B.pdf в порядке нескольких пикселей здесь и там, но НЕТ в отслеживание тестированной строки.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top