https://bugs.winehq.org/show_bug.cgi?id=42739
Bug ID: 42739 Summary: CUPS PDF creation, font encoding, garbled / glibberish text Product: Wine Version: 2.4 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineps.drv Assignee: wine-bugs@winehq.org Reporter: quatze@t-online.de Distribution: ---
Created attachment 57734 --> https://bugs.winehq.org/attachment.cgi?id=57734 Original docx file
This has originally been posted in the forum, see here: https://forum.winehq.org/viewtopic.php?f=8&t=28673
I am running MSOffice 2007 on Wine 2.4 on Arch. It is running very well and I am using it to prepare PDF files from various office files in the background. The PDF files look very good and are searchable. However, they contain text, which is malformed. This depends on the font encoding, I suppose.
As a test setup I copied my Fonts directory from my windows machine to the respectuive wine prefeix/drive_c/windows/Fonts and also installed them in the truetype fonts directory on the linux machine (/usr/share/fonts/TTF + fc-cache and fc-cache-32). So the PDF printing picks up all necessary fonts.
Printing is done via cups-pdf. Currently at 3.0.1, but I have tried several versions starting from 2.6 inclduding and not indcluding several patches found on the internet:
https://github.com/alexivkin/CUPS-PDF-to-PDF http://www.linuxquestions.org/questions ... 175440557/ https://launchpadlibrarian.net/15378121 ... port.patch
It seems that the cups-pdf driver is not the culprit here, as the result is always the same.
My test.docx is attached and contains two lines ('test') the first one in Calibri, the second one in Arial. When I print this docx with wine 2.4, Word 2007 and cups-pdf, a pdf file is created, which looks fine (s. attached), but when I copy and paste the text, I get:
'[garbled text] test'
So apparently, the Calibri-font part is somehow problematic.
pdffonts test_wine.pdf OQHKQC+ArialMT Type 1C WinAnsi yes yes no 10 0 YIGKZZ+Calibri Type 1C Custom yes yes no 8 0
I know I can directly save the docx as a pdf in word and I can also automate this via a makro, but I also would like to print from Outlook, which is not as easy to automate as Word via makros, but easily prints via tjhe /p command line switch.
When I directly save the docx as pdf, I get:
'Test test'
pdffonts test_wine_savepdf.pdf ABCDEE+Calibri TrueType WinAnsi yes yes no 5 0 Arial TrueType WinAnsi no no no 7 0
The difference is that the Calibri font is encoded WinAnsi and not custom.
I checked whether the cups-pdf driver might be the culprit by opening and printing the test.docx file with a native copy of libreoffice and I get:
'Test test'
pdffonts test_lo.pdf BAAAAA+Calibri TrueType WinAnsi yes yes yes 14 0 CAAAAA+ArialMT TrueType WinAnsi yes yes yes 9 0
So, basically, both the cups-pdf driver and wine/word are able to encode WinAnsi, but printing via Word apparently forces the cups-pdf driver to include custom-encoded font-subsets. I somewhere read that ghostscript cannot do anything related to reencoding fonts, so I assume that there is something wrong before cups-pdf starts.
Further observations:
If I use the 'print to file' option in Word (wine) and Word (Windows machine) to produce a PS file, further processing with ghostscript produces a PDF with garbled copied text and Type 1C, Custom encoding Calibri, whilst the same command produces a PDF with copiable text and TrueType, WinAnsi encoding Calibri.
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #1 from marlemion quatze@t-online.de --- Created attachment 57735 --> https://bugs.winehq.org/attachment.cgi?id=57735 wineps created PS file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #2 from marlemion quatze@t-online.de --- Created attachment 57736 --> https://bugs.winehq.org/attachment.cgi?id=57736 wineps / CUPS-pdf created PDF file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #3 from marlemion quatze@t-online.de --- Created attachment 57737 --> https://bugs.winehq.org/attachment.cgi?id=57737 wineps / gs created PS file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #4 from marlemion quatze@t-online.de --- Created attachment 57738 --> https://bugs.winehq.org/attachment.cgi?id=57738 wine / Word save as pdf - created PDF file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #5 from marlemion quatze@t-online.de --- Created attachment 57739 --> https://bugs.winehq.org/attachment.cgi?id=57739 Native Libreoffice created PDF file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #6 from marlemion quatze@t-online.de --- Created attachment 57740 --> https://bugs.winehq.org/attachment.cgi?id=57740 Windows created PS file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #7 from marlemion quatze@t-online.de --- Created attachment 57741 --> https://bugs.winehq.org/attachment.cgi?id=57741 Windows / gs created PDF file
https://bugs.winehq.org/show_bug.cgi?id=42739
marlemion quatze@t-online.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #57737|wineps / gs created PS file |wineps / gs created PDF description| |file
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #8 from marlemion quatze@t-online.de --- Created attachment 57747 --> https://bugs.winehq.org/attachment.cgi?id=57747 Print with WINEDEBUG='+psdrv'
get_download_name Got Mac PS name "Calibri" <-- maybe this is a hint
https://github.com/wine-compholio/wine-patched/blob/master/dlls/wineps.drv/d...
http://marc.info/?l=wine-patches&m=117034220426649
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #9 from marlemion quatze@t-online.de --- Tested the same document with Wordviewer. Same result.
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #10 from marlemion quatze@t-online.de --- I did some further research and some discussion, s. here: https://github.com/alexivkin/CUPS-PDF-to-PDF/issues/2
To sum up, I ruled out ghostscript to be the issue by transforming the PS file created via the 'print to file' option of word under wine using Acrobat (v. 8.0). The result was the same, Calibri was not searchable. This was done on a windows machine. Therefore, I assume that the text is already lost when wineps prints it.
Furthermore, I installed the Adobe PS generic driver under wine and printed with this one 'to a file'. The resulting ps file differed only marginally from the ps file created with the cups-pdf printer and 'print to file' option. The issue also is still there with this file.
Accordingly, the issue _must_ be somewhere in the wineps.drv. I really would like to debug some more, but I don't know how.
https://bugs.winehq.org/show_bug.cgi?id=42739
--- Comment #11 from marlemion quatze@t-online.de --- So I investigated further this issue and came across a solution.
Apparently, the culprit lies within a missing feature rather than a bug.
When reading the output of wine while printing, I came across the line:
"postscript format 3.0 glyph names are currently unsupported"
So I dug into the source code and found the respective distinction in download.c of dlls/wineps.drv/. Here, it is distinguished between the formats type 1, type 2 and type 3. Apparently, the code transforms the truetype font to an intermediate postscript font. For that, it needs to know the name of the glyphs. This is exactly extracted at this position.
However:
ttf2afm /usr/share/TTF/calibri.ttf > /dev/null
Warning: ttf2afm (file /usr/share/TTF/calibri.ttf): no names available in `post' table, print glyph names as indices
Bingo! So I understood that the culprit lies within the missing name tables of the font itself. As long as there is no support in wine for these fonts, one hase to transform the fonts including the name tables. I found a solution here:
https://github.com/fontforge/designwithfontforge.com/issues/16
And adopted it for my needs:
#! /usr/bin/env python import fontforge import sys
fontfile = sys.argv[1]
try: font = fontforge.open (fontfile) except EnvironmentError: sys.exit (1)
for glyph in font: if font[glyph].unicode != -1: font[glyph].glyphname = fontforge.nameFromUnicode (font[glyph].unicode, "Adobe Glyph List")
font.save (fontfile)
For every font having no names table, I executed this script (you need fontforge for it):
#!/bin/bash for i in *; do if [[ $(ttf2afm $i 2>&1) == *"no names available"* ]]; then echo $i && above_script.py $i && echo; fi; done exit 0
That's it.
https://bugs.winehq.org/show_bug.cgi?id=42739
Detlef Riekenberg wine.dev@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |printing CC| |wine.dev@web.de
--- Comment #12 from Detlef Riekenberg wine.dev@web.de ---
Thanks for your detailed report and the workaround.