Issue 111292 - Missing fonts in exported PDF when running -headless
Summary: Missing fonts in exported PDF when running -headless
Status: CONFIRMED
Alias: None
Product: udk
Classification: Code
Component: code (show other issues)
Version: OOo 3.2
Hardware: Unknown Linux, all
: P3 Trivial with 10 votes (vote)
Target Milestone: 4.x
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-30 15:09 UTC by mnasato
Modified: 2013-11-26 10:50 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Simplified Chinese document (33.00 KB, application/msword)
2010-04-30 15:10 UTC, mnasato
no flags Details
Exported PDF in normal mode (173.30 KB, application/pdf)
2010-04-30 15:11 UTC, mnasato
no flags Details
Exported PDF in headless mode (86.58 KB, application/pdf)
2010-04-30 15:11 UTC, mnasato
no flags Details
Converter script (7.72 KB, text/x-python)
2010-04-30 15:12 UTC, mnasato
no flags Details
Exported PDF in normal mode (165.91 KB, application/pdf)
2010-09-09 19:59 UTC, mnasato
no flags Details
Exported PDF in headless mode (95.24 KB, application/pdf)
2010-09-09 20:00 UTC, mnasato
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description mnasato 2010-04-30 15:09:34 UTC
Exporting documents with e.g. Chinese fonts to PDF on Linux usually works fine,
but not when soffice is started with the -headless switch. In that case, fonts
are missing.

It seems like the font resolution mechanism used for -headless is somewhat
different?
Comment 1 mnasato 2010-04-30 15:10:31 UTC
Created attachment 69200 [details]
Simplified Chinese document
Comment 2 mnasato 2010-04-30 15:11:17 UTC
Created attachment 69201 [details]
Exported PDF in normal mode
Comment 3 mnasato 2010-04-30 15:11:43 UTC
Created attachment 69202 [details]
Exported PDF in headless mode
Comment 4 mnasato 2010-04-30 15:12:18 UTC
Created attachment 69203 [details]
Converter script
Comment 5 mnasato 2010-04-30 15:17:31 UTC
Here's how I can reproduce the issue.

To export to PDF in headless mode:
$ /opt/openoffice.org3/program/soffice -headless "-accept=socket,port=8100;urp;" &
$ /opt/openoffice.org3/program/python DocumentConverter.py tuoguan.doc tuoguan.pdf

To export to PDF in normal mode: same as above without the -headless switch.

I have a few Chinese fonts installed on my system (Ubuntu Linux 10.04) like
ttf-wqy-microhei that appear in the "normal" PDF but not in the headless one.
Comment 6 mnasato 2010-04-30 15:19:18 UTC
Note that the same problems occurs with spreadsheets, presentations, etc.
Comment 7 mnasato 2010-05-01 10:57:12 UTC
I suspect the problem is related to the Chinese fonts being *.ttc (rather than
*.ttf).
Comment 8 kay.ramme 2010-05-04 07:09:46 UTC
Philipp, any clue about this?
Comment 9 philipp.lohmann 2010-06-04 13:53:03 UTC
target
Comment 10 philipp.lohmann 2010-06-04 13:53:27 UTC
ad hdu to CC
Comment 11 hdu@apache.org 2010-06-04 14:13:31 UTC
@mnasato: there is a file named "pspfontcache" in the .openoffice* directory for each user. Please 
compare these files. I guess the headless user doesn't get to know all the available fonts.
Comment 12 mnasato 2010-06-04 14:33:36 UTC
@hdu thanks for the idea but I don't think that's the cause: in my test to
reproduce the issue (see comment) I was running OOo under the same user, just
with and without the -headless switch.

I've just retried after deleting and recreating ~/.openoffice.org -> same results.
Comment 13 mnasato 2010-06-04 14:55:04 UTC
BTW .openoffice.org/3/user/psprint/pspfontcache does contain the required font:

FontCacheDirectory:1272641165:/usr/share/fonts/truetype/wqy
File:wqy-zenhei.ttc
2;2
WenQuanYi Zen Hei;文泉驛正黑;文泉驿正黑
0;WenQuanYiZenHei;0;6;5;2;65535;962;250;212;0;1175;1212;1175;1212;0;1;1;8;中等
WenQuanYi Zen Hei Mono;文泉驛等寬正黑;文泉驿等宽正黑
1;WenQuanYiZenHeiMono;0;6;5;2;65535;962;250;212;0;1175;1212;1175;1212;0;1;1;8;中等

(I have ttf-wqy-zenhei installed now instead of ttf-wqy-microhei, but the
behaviour is the same.)
Comment 14 sergey_ch 2010-08-25 13:49:41 UTC
*** Issue 111292 has been confirmed by votes. ***
Comment 15 hdu@apache.org 2010-09-08 12:49:34 UTC
Both the "bad headless" PDF and the "good non-headless" PDF look identical in
acroread, xpdf and OSX's preview... also the tool diffpdf claims that they look
identical. Wich PDF viewer is supposed to show the problem?
Comment 16 mnasato 2010-09-08 18:54:38 UTC
They're clearly not All PDF viewers on my Ubuntu Linux machine, i.e. acroread, 
evince, chrome. Maybe
Comment 17 mnasato 2010-09-08 19:00:15 UTC
(Sorry for the last comment, somehow I submitted it while still editing it.)

I just tried on both Linux and Windows with Adobe Reader and other readers and in 
all cases the headless one does not show correctly. And the two files clearly 
have different sizes.
Comment 18 hdu@apache.org 2010-09-09 12:12:20 UTC
On a closer look the provided PDF from the headless client shows that it was created by different version 
than its non-headless counterpart. The headless version seem to be patched a up derivative of upstream 
OOo, e.g. the entries in the FontDescriptor  entry are sorted alphabetically while upstream OOo does not 
do this. So which patched version of OOo were you using for headless example?
Comment 19 mnasato 2010-09-09 18:40:57 UTC
I created the two files exactly as described in my first (non-attachment) comment 
that explains how to reproduce the issue, using the same version of OOo 3.2 
downloaded from openoffice.org, just with and without the -headless switch.
Comment 20 mnasato 2010-09-09 19:57:34 UTC
Actually, I can't be 100% sure of what I did back in April now, so I'll just go 
through the same steps again and attach new files.

It would be great if you could try and reproduce the issue using the same method 
too.
Comment 21 mnasato 2010-09-09 19:59:44 UTC
Created attachment 71631 [details]
Exported PDF in normal mode
Comment 22 mnasato 2010-09-09 20:00:39 UTC
Created attachment 71632 [details]
Exported PDF in headless mode
Comment 23 hdu@apache.org 2010-09-10 15:17:20 UTC
Setting the env-variable SAL_DISABLE_FC_SUBST before starting the app in non-
headless mode results in the same exported PDF as the app in headless mode,
because headless mode doesn't request external font substitutors. And the
internal ones do know neither 黑体 nor SimHei (requested in the doc) nor
WenQuanYi.

If you want SimHei to be always substituted by a member of the WenQuanYi family
(if SimHei is not available) then please extend VCL.xcu accordingly.

If you want to have the full blown capacity of the non-headless app with all
its resource requirements including all the libraries and config-files also
needed by the non-headless version then the question has to be asked why bother
with headless mode at all? Having the one window mapped is not costly.
Comment 24 mnasato 2010-09-10 19:04:55 UTC
Well, at least you are now implicitly acknowledging that there *is* a difference 
in PDF output between headless and not headless, and it doesn't depend on which 
PDF viewer you use or on a patched version of OOo.

That said, I have no idea of what VCL.xcu I'm afraid. To reverse your argument, 
what's the point of having a headless version if it doesn't behave like the 
normal one?
Comment 25 philipp.lohmann 2011-02-08 14:27:06 UTC
Resetting target accroding to new task handling scheme announced here:

http://blogs.sun.com/ratte/entry/some_changes_for_the_openoffice
Comment 26 piti 2012-05-11 11:26:53 UTC
I can confirm the exact same behavior with openoffice 3.3, downloaded on january 2012. (I added a comment because the bug has remained untouched since 2010)
Comment 27 Maxim 2012-09-18 12:10:19 UTC
(In reply to comment #23)
> Setting the env-variable SAL_DISABLE_FC_SUBST before starting the app in non-
> headless mode results in the same exported PDF as the app in headless mode,
> because headless mode doesn't request external font substitutors. And the
> internal ones do know neither 黑体 nor SimHei (requested in the doc) nor
> WenQuanYi.
> 
> If you want SimHei to be always substituted by a member of the WenQuanYi
> family
> (if SimHei is not available) then please extend VCL.xcu accordingly.
> 
> If you want to have the full blown capacity of the non-headless app with all
> its resource requirements including all the libraries and config-files also
> needed by the non-headless version then the question has to be asked why
> bother
> with headless mode at all? Having the one window mapped is not costly.

Hi,

Can you elaborate a bit more on how I should extend Open Office configuration to solve this particular issue? There is no VCL.xcu file.

If I understand it correctly, if the system misses some font, then it is not substituted in headless mode. Is there a workaround for this (so OOo in headless mode works with fonts equally to non-headless mode)?
Comment 28 Rob Weir 2013-07-30 02:17:21 UTC
Reset assignee on issues not touched by assignee in more than 2000 days.
Comment 29 Fred 2013-11-26 10:50:13 UTC
Any updates or workarounds on this?