Issue 113195 - PDF builtin fonts not working anymore on Mac
Summary: PDF builtin fonts not working anymore on Mac
Status: CLOSED FIXED
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.0.0
Hardware: Mac Mac OS X 10
: P3 Trivial (vote)
Target Milestone: 3.4.0
Assignee: hdu@apache.org
QA Contact: issues@gsl
URL:
Keywords: aqua
Depends on:
Blocks:
 
Reported: 2010-07-16 14:00 UTC by philipp.lohmann
Modified: 2010-07-16 15:08 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description philipp.lohmann 2010-07-16 14:00:17 UTC
The fix for issue 109651 was to disable builtin fonts wholesale. That is not a
good solution, please enable them again.
Comment 1 hdu@apache.org 2010-07-16 14:13:49 UTC
The 14fonts known as PDF base fonts are on OSX also available as system fonts which are heavily 
extended vs. their iso8859-1-only builtin counterparts. If there was a way to know early that the builtins 
supported everything that is requested from them (i.e. only iso8859-1) reenabling them would be trivial. 

This info is not available from the apps though. Also having a mixture of builtin- and their system-
counterpart fonts in the same line for alternating glyphs has many more disadvantages. Issue 109651 was 
just one obvious example.
Comment 2 philipp.lohmann 2010-07-16 14:19:59 UTC
Then I guess reenabling them is indeed trivial, since their exact are described
in their font descriptor: "WinAnsiEncoding".
Comment 3 hdu@apache.org 2010-07-16 14:44:37 UTC
The important question is whether the app+doc has some texts where a builtin-font candidate is selected 
and the base14-coverage does not suffice. We already know that the builtin fonts do not cover anything 
beyond their ansi-only codepoints.

And even when they are covered there are interesting scenarios what to do with combinations such a 'A' 
with U+0306 (breve). Should the 'A' come from the builtin-font and the Breve from its system-font 
counterpart? The system-font suggests a ligature and updates the positioning, as it knows the detailsfrom 
its "morx" table. When there are such gray areas of course the best solution is to always trust the system 
font, which is what we do now.
Comment 4 hdu@apache.org 2010-07-16 14:58:02 UTC
As an additional data point: the Quart-builtin-PDF-export embeds the required subset from the system-
fonts and does not try to use a base14 even if it was possible. Now we behave so to and integrate better 
with the system.
Comment 5 philipp.lohmann 2010-07-16 15:06:00 UTC
The Quartz built-in print to PDF omits a lot of features that we have, e.g.
hyperlinks and form controls. Specifically the "Quartz PDF export" does not have
a checkbox giving the user the opportunity to disable use of the 14 base fonts.

We on the other hand have such - which is now useless. Those who have a problem
with the built-in fonts can disable them - only not anymore on Mac. Worse those
that explicitly do not want to blow up their tiny 26k PDF document by 500k of
font subsets now don't have that option anymore. That simply sucks, so please
enable built-in fonts again.
Comment 6 philipp.lohmann 2010-07-16 15:07:52 UTC
fixed in CWS vcl113 again, kicked out issue 109651
Comment 7 philipp.lohmann 2010-07-16 15:08:11 UTC
closing