View Issue Details

IDProjectCategoryView StatusLast Update
0012973ScribusFontspublic2015-04-26 15:18
Reporteravox Assigned Toavox  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformMacOSOSXOS VersionYosemite
Product Version1.5.0svn 
Target Version1.5.0Fixed in Version1.5.0svn 
Summary0012973: TTF embedding doesnt work
DescriptionWhen embedding a TTF font like ApplyMyungo, Adobe Reader only shows rectangles instead of glyphs
Steps To ReproduceExport as PDf 1.4, no compression, embed no subset
TagsNo tags attached.
PatchNo

Activities

avox

2015-04-03 15:31

administrator  

Dokument-1.sla (14,962 bytes)

avox

2015-04-03 16:06

administrator  

Dokument-1r.pdf (457,742 bytes)

avox

2015-04-03 16:08

administrator   ~0034813

Added PDF with Times Roman. Issue apparently only occurs with (original format) TrueType fonts, "OpenType Truetype" works.

avox

2015-04-12 15:45

administrator   ~0034898

Identified 2 problems:
- ttc (font collection) embedding was broken
- Adobe Reader only consults the AdobeGlyphList if there is a MS Unicode cmap (3,1) or MacRoman cmap (1,0) present. If the font only contains a Apple Unicode cmap (0, x), AR will use the TTF post table to resolve glyph names. /uni0123 style glyphnames are the exception in most post tables, so the encoding Scribus generates fails.

avox

2015-04-12 17:39

administrator   ~0034900

see commit 20001

Needs some testing for Windows and Linux but I don't expect drawbacks.

jghali

2015-04-12 20:20

administrator   ~0034903

Last edited: 2015-04-12 20:29

TTF fonts which have a Apple unicode cmap and no glyph name table are still not embedded as embedding fallback and use a collection of XObjects, not even a Type 3 fonts.

When subsetting, the new code cause a regression : previously these fonts were subset as Type 3 fonts, now they are embedded as a collection of XObjects (bad for text searchability).

I think more and more we should use the 2-byte Identity-H encoding for all TTF fonts. It seems to work also in that case and allows real embedding, not a fallback to XObjects like currently.

For information I stumbled about that post on FreeType mailing list:
https://lists.gnu.org/archive/html/freetype-devel/2007-10/msg00004.html
It suggest a font may have both an Apple and Microsoft unicode cmap and MS cmap is more reliable in such case. Currently I'm not sure if Freetype will present us those two cmaps or only the MS cmap. In the former case we should likely add a safeguard in scfontmetrics setBestEncoding() in order to favor MS cmap.

avox

2015-04-22 18:56

administrator   ~0034963

Ok, new version checks post table before use and falls back to Identity-H encoding.

avox

2015-04-22 18:59

administrator   ~0034964

add code to check post table, don't use XForm embedding any more (Type3 + AGL works fine even if we don't have names)

Issue History

Date Modified Username Field Change
2015-04-03 15:31 avox New Issue
2015-04-03 15:31 avox Status new => assigned
2015-04-03 15:31 avox Assigned To => avox
2015-04-03 15:31 avox File Added: Dokument-1.sla
2015-04-03 16:06 avox File Added: Dokument-1r.pdf
2015-04-03 16:08 avox Note Added: 0034813
2015-04-12 15:45 avox Note Added: 0034898
2015-04-12 17:39 avox Note Added: 0034900
2015-04-12 17:39 avox Status assigned => resolved
2015-04-12 17:39 avox Fixed in Version => 1.5.0svn
2015-04-12 17:39 avox Resolution open => fixed
2015-04-12 20:20 jghali Note Added: 0034903
2015-04-12 20:29 jghali Note Edited: 0034903
2015-04-12 20:33 cbradney Status resolved => feedback
2015-04-22 18:56 avox Note Added: 0034963
2015-04-22 18:56 avox Status feedback => assigned
2015-04-22 18:59 avox Note Added: 0034964
2015-04-22 18:59 avox Status assigned => resolved
2015-04-26 15:18 cbradney Status resolved => closed