Apache OpenOffice (AOO) Bugzilla – Issue 110387
otf font can not be printed in non-english locale
Last modified: 2017-05-20 11:41:46 UTC
A document, which contains opentype fonts, can not be printed per printer or per cups-pdf. There arrives only one blank white paper (1 page): No text at all. Cups mentions a problem. The build-in pdf-function produces a pdf ("OO-PDF") included the text in opentype font. But the OO-PDF can not be printed by Adobe Reader ("The document could not be printed"). PDFs from other applications like Scribus can be printed. Evince Document Viewer 2.28.1 is able to print the OO-PDF, but there is other known problem with evince in linux karmic (it shrinks the printed pagesize), so I can not use it. 1. This issue happens only in the Linux-Version of OO 3.2. There is no problem in the Windows XP-Version. 2. I use Linux Mint/8 Helena (based on ubuntu karmic). 3. I use a Dell 1320c network printer with the driver FX DocuPrint C525 A-AP v1.0. 4. I installed OO 3.2 manually from here: http://download.services.openoffice.org/files/localized/de/3.2.0/OOo_3.2.0_LinuxIntel_install_de_deb.tar.gz 5. The opentype font - named Delicious (a very nice free font: http://www.josbuivenga.demon.nl/delicious.html ) - is correct installed. 6. I tried it also with another opentype font named Miso. 7. Scribus 3.6 or GIMP do not show this issue. 8. I reinstalled the whole system twice.
Created attachment 68542 [details] No otf fonts used, printed with cups-pdf
Created attachment 68543 [details] No otf fonts used, build-in OO-PDF
Created attachment 68544 [details] otf fonts DELICIOUS used, blank pdf, printed with cups-pdf
Created attachment 68545 [details] otf fonts DELICIOUS used, build-in OO-PDF
Created attachment 68546 [details] otf fonts MISO used, blank pdf, printed with cups-pdf
Created attachment 68547 [details] otf fonts MISO used, build-in OO-PDF
I confirm the problem with OOo 3.2.0 FR under Ubuntu 8.04. I downloaded Delicious OpenType font and created a text document with some dummy text. When I print the document from OpenOffice.org (File > Print) I obtain only a blank page and the print job stays in the print queue with state "in progress" ("traitement en cours" in French). I exported the text doc as pdf, opened it with Evince and printed without problem. Printer is a Canon Pixma MP270 accessed through the local network. Regards. JBF
Could not reproduce with own created document in opensuse Please provide also the odt file. Thanks.
cc myself
Created attachment 68621 [details] file which use delicious otf font
Created attachment 68622 [details] pdf export with delicious otf font integrated
Attached both files I made to test this issue, the odt and its export to pdf. Regards. JBF
Okay, I noticed something: The printer has to be connected to show the failure message (german: "Druck-Fehler. Es gibt ein Problem mit der Verarbeitung des Dokuments "OTF-Test Delicious" (job ##)."). I tried to print the document for another time, but I couldn't be sent to the printer because the printer wasn't switched on. When I switched the printer on, the failure message appeared. 1. Maybe it's something with the communication or how the document is sent to the printer, because it needs to communicate with the printer to show the failure notice. 2. In which directory is your font installed in opensuse? I'll attach the original odt file, but I don't think it is a problem with the document but maybe where the font is or is not found in the system.
Created attachment 68625 [details] the ODT File
OK, I'll attach my both results; cups-pdf print & pdf-export My fonts directory: /usr/share/fonts Maybe I have to find a ubuntu machine?
Created attachment 68638 [details] My cups-pdf result
Created attachment 68639 [details] My pdf-export result
For my tests I installed the font in ~/.fonts. After having restarted OOo it found the font without problem. Same problem if I install the font in /usr/share/fonts and update the font cache. Regards.JBF
It seems there is a problem with delicious font : I assigned Delicious Roman to standard style but when I reopen the file and do Format > Character OOo says that the font is Delicious Regular and that "this font will simulated or the closest matching style will be used". Same problem with Dev300_m75. Regards. JBF
@HDU: Please take a look. Thanks.
@jbf: I confirm this problem. The following message is shown: "Dieser Schriftstil wird nachgebildet oder der am besten passende Stil wird verwendet." = "this font will simulated or the closest matching style will be used". But: It's not a problem of the font Delicious. I receive the same printing problem with other otf-fonts like "Linux Libertine O" (in the otf-version). I will attach the ps-files (print to file). Maybe the can help by comparison with ps-files from other linux systems like opensuse. Best regards
Created attachment 68691 [details] Postscript-file of the OTF-Test-Document
Created attachment 68692 [details] Test with a text in Linux Libertine
Created attachment 68693 [details] No otf fonts used, printed with cups-pdf and print-to-file
I tested opensuse 11.2 with openoffice.org 3.2 now. Same result: no printing of documents which contain otf fonts. @hi: Could you please give me more information about your system? Which versions of opensuse and cups are running? Best Regards
@parsival: Sure, my opensuse is 11.0 and cups 1.3.7 Would be interesting if you have the same configuration like me. @PL: Please take a look to the both OTF*.ps files. Thanks. Regards HI
@hdu: please have a look
Indeed, the font checker complains about "Bad BlueScale entry in PostScript Private dictionary" caused by the entry "/BlueScale 0,328541 def" whereas it should use the dot instead of the comma: "/BlueScale 0.328541 def" So it seems that a libc tries to be too smart with the locale when doing a printf. @parsival: could you test this theory by setting an environment variable export LC_NUMERIC="en_US.UTF-8" and starting soffice from that command line? Make sure that no other instances of OOo are running.
Fixed in CWS fwk140.
@hdu: great! You made my day ;) I tried so many different settings before and couldn't figure out, what was going on. Now, I tested it like you said. I set up the environment variable with the command export LC_NUMERIC="en_US.UTF- 8" and started openoffice from that command line. It worked out perfect for me. The document was printed. @all: thanks for you awesome work on openoffice!
@parsival: thanks for checking that the problem and its solution are fully understood. The fix will get into OOo321. While we are at it: What did "locale -a" report before the LC_NUMERIC workaround? Which language of OOo was installed? Also do not forget to test the release candidate when it comes out.
@hdu: I don't know what "locale -a" would have reported before I typed in the workaround for the first time, but the recent result (before setting up the enviroment variable with the command export LC_NUMERIC="en_US.UTF- 8" ) is: hotchip@minirechner ~ $ locale -a C de_AT.utf8 de_BE.utf8 de_CH.utf8 de_DE.utf8 de_LI.utf8 de_LU.utf8 en_AG en_AU.utf8 en_BW.utf8 en_CA.utf8 en_DK.utf8 en_GB.utf8 en_HK.utf8 en_IE.utf8 en_IN en_NG en_NZ.utf8 en_PH.utf8 en_SG.utf8 en_US.utf8 en_ZA.utf8 en_ZW.utf8 POSIX It's the same result as on my desktop-system where I have not set up the enviroment variable yet. I installed the german version of OOo 3.2.0 from here: http://download.services.openoffice.org/files/localized/de/3.2.0/OOo_3.2.0_LinuxIntel_install_de_deb.tar.gz Sure, I will test the release candidate asap.
@es: please verify in CWS fwk140 Testing hints: - use the attached font - use a locale and an install set of a language where the fractional separator is not a dot, e.g. in de or fr locales the value 1.2 is written as 1,2
linux install set available for testing at ftp://qa-upload.services.openoffice.org/fwk140/linux-intel/OOo_3.2.1_100414_unxlngi6_install.tar.gz
@parsival: can you please verify ASAP (we are on time constrains for 3.2.1) that this problem is fixed in the CWS (see ftp hyperlink posted in last comment)? Thank You!
@es: Sure, I would, but how does it work? I never tried such a development version. I wasn't able to find a introduction in testing these builds. @all: Could anybody please explain to me what to do?
1. download the tarball using the link PL provided 2. open a terminal 3. run "mkdir a_directory_somewhere" 4. run "cd a_directory_somewhere" 5. run "tar xvzf tarball_file.tgz" (after you replaced tarball_file.tgz with the filename of the file you downloaded) 6. run "find . -name soffice" 7. start that soffice just found 8. do your tests
@hdu: thanks for your help @es: It works. I tested the CWS fwk140 and was able to print directly and with the cups-pdf-function. I tested it also on my desktop-system. Both systems are Ubuntu-based (Karmic): Linux mint 8; german enviroment. I will attach the test-files.
Created attachment 68940 [details] ps-file made with cups-pdf-function (printing in CWS fkw140)
Created attachment 68941 [details] direct printing to ps-file
Created attachment 68942 [details] pdf-file made with CWS fkw140 build-in-pdf-function
marked issue as verified (as it was done by parsival)
@parsival: Thanx a lot for verifying this! :)