Issue 111292

Created attachment 69200 [details]
Simplified Chinese document

Created attachment 69201 [details]
Exported PDF in normal mode

Created attachment 69202 [details]
Exported PDF in headless mode

Created attachment 69203 [details]
Converter script

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.

Note that the same problems occurs with spreadsheets, presentations, etc.

I suspect the problem is related to the Chinese fonts being *.ttc (rather than
*.ttf).

Philipp, any clue about this?

target

ad hdu to CC

@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.

@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.

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.)

*** Issue 111292 has been confirmed by votes. ***

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?

They're clearly not All PDF viewers on my Ubuntu Linux machine, i.e. acroread, 
evince, chrome. Maybe

(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.

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?

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.

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.

Created attachment 71631 [details]
Exported PDF in normal mode

Created attachment 71632 [details]
Exported PDF in headless mode

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.

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?

Resetting target accroding to new task handling scheme announced here:

http://blogs.sun.com/ratte/entry/some_changes_for_the_openoffice

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)

(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)?

Reset assignee on issues not touched by assignee in more than 2000 days.

Any updates or workarounds on this?