Issue 85824

Summary: OOH680_m6: PDF Export: the 14 PDF standard fonts are always exported.
Product: gsl Reporter: Giuseppe Castagno (aka beppec56) <giuseppe.castagno>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: issues, pavel
Version: OOH680m5   
Target Milestone: OOo 3.x   
Hardware: PC   
OS: Linux, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
Writer document used for test none

Description Giuseppe Castagno (aka beppec56) 2008-02-03 16:41:23 UTC 
On GNU/Linux Debian, home build OOH680_m6 tag.

The 14 PDF standard fonts are always exported, even when exporting to non-PDF/A-1a.
The attached document contains all the 14 standard PDF fonts, to check as follows:
1)open the document with OOH680_m6
2)confirm the PDF/A-1a checkbox on the general tab as unchecked and export the file
3)open the file with Acrobat Reader
4)look at  “File > Properties > (tab) Fonts”: the fonts are all embedded.

Repeat the operation with a 2.3.1 version, the fonts are not embedded.

-> pl. I did some debug on a m245 version I'm working on. It seems the up to
PDFWriterImpl::filterDevFontList the 14 fonts are loaded into pFiltered.

So I think this is outside the PDF/A-1a stuff, since the PDF/A-1a is not touched
by this behavior.
What changes is the size of the PDF file when the user chose the standard fonts
to have the PDF smaller...

Last observation is about the font chosen to display the standard ones that are
different than the one used for vanilla 2.3.1, on the same PC.
In any case I think that some tests on other platform should be in order before
confirming, may be I'm plainly wrong.
Comment 1 Giuseppe Castagno (aka beppec56) 2008-02-03 16:42:23 UTC 
Created attachment 51332 [details]
Writer document used for test
Comment 2 philipp.lohmann 2008-02-05 15:17:06 UTC 
confirm
Comment 3 philipp.lohmann 2008-02-05 15:17:38 UTC 
Herbert ?
Comment 4 hdu@apache.org 2008-02-05 15:29:12 UTC 
It seems that the fontconfig integration from issue 54603 suggests that the fonts should be replaced. 
Type "fc-match Times" to see how fontconfig wants Times to be replaced. OOo respecting these system 
wide global configuration setting is a kind of feature... disabling it for PDF export only or for the base14 
fonts contradicts the spirit of this deeper system integration, which is heavily requested by the 
distributions.
Comment 5 Giuseppe Castagno (aka beppec56) 2008-02-06 10:31:43 UTC 
-> hdu. Checked with fc-match Times, result:
fc-match -s Times | head
timR12.pcf.gz: "Times" "Regular"
n021003l.pfb: "Nimbus Roman No9 L" "Regular"
Times_New_Roman.ttf: "Times New Roman" "Normal"
DejaVuSerif.ttf: "DejaVu Serif" "Book"

I guess the second line it's the one honored by OOo. So OOo behaves according to
fontconfig configuration.
But the chosen font is a Type1 font and since it's not subsetted while exporting
to PDF. as a side effect the PDF becomes larger then before 2.4, expecially on
small files (e.g. the file I submitted is ~ 12k, becomes 1M when exported).

It seems that with the OOo font replacement table you can't overcome this issue.
On Tools > Options > OOo > Fonts I added the following table (wasn't there on
first try):

Courier > replaced by Courier New
Helvetica > replaced by Arial
Symbol > replaced by Standard Symbols L
Times > replaced by Times New Roman
Zapf DingBats > replaced by Dingbats

I chose most of the TTF I have installed on my Linux  box. Then I ticked both
Always and Screen checkboxes.
But only the rows with 'Symbol' and Zapf Dingbats were honored by OOo, not the
others.
Is this expected?

Or the only way to change the font substitution behavior in platforms using
fontconfig is by changing the fonconfig configuration data?

Last, I agree that issue 54603 is a good improvement, but shouldn't OOo have the
substitution table take precedence over the fontconfig settings?
Comment 6 hdu@apache.org 2008-06-03 09:09:22 UTC 
retargeting
Comment 7 Marcus 2017-05-20 11:33:50 UTC 
Reset assigne to the default "issues@openoffice.apache.org".