Bug 696808 - Status of OpenType Collection support
Summary: Status of OpenType Collection support
Status: RESOLVED INVALID
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: Font API (show other bugs)
Version: unspecified
Hardware: PC Linux
: P4 normal
Assignee: Chris Liddell (chrisl)
QA Contact: Bug traffic
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-29 23:18 UTC by Werner Lemberg
Modified: 2016-09-16 13:31 UTC (History)
1 user (show)

See Also:
Customer:
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Werner Lemberg 2016-05-29 23:18:31 UTC
It seems that ghostscript currently doesn't support OpenType Collections (OTC).  Are there plans to support it?

Similarly, will ghostscript extend its Type42 support so that it can handle arbitrary SFNT fonts, including OTCs?  Right now I'm wondering whether I should do that in FreeType...

Or asking differently: What format should be used if you want to have an OTC as a PostScript resource embedded into a PS file?
Comment 1 Chris Liddell (chrisl) 2016-05-29 23:39:50 UTC
(In reply to Werner Lemberg from comment #0)
> It seems that ghostscript currently doesn't support OpenType Collections
> (OTC).  Are there plans to support it?
> 
> Similarly, will ghostscript extend its Type42 support so that it can handle
> arbitrary SFNT fonts, including OTCs?  Right now I'm wondering whether I
> should do that in FreeType...
> 
> Or asking differently: What format should be used if you want to have an OTC
> as a PostScript resource embedded into a PS file?

You can't - Postscript does not support Opentype fonts at all, nor does it support Truetype Collections. In fact, Postscript doesn't even support Truetype fonts, only Type 42 - okay, strictly speaking, Type 42 is largely just a thin wrapper around a TTF.....

We're not really in a position to change what's included in the Postscript spec.

*Ghostscript* (so outside the realms of the Postscript spec) has custom extensions to allow wider support for font loading from disk.

For embedding the content of a OTTO or OTC in Postscript, you would have to extract the CFF (from the appropriate index, in the case of an OTC), and embed the CFF stream as a Postscript Type 2 font.


Better support for reading TTC, OTTO and OTC font files from disk are certainly on my to-do list, but haven't yet reached the top the list. But once done, our Postscript output will still not contain a TTC/OTTO/OTC font, but the closest Postscript legal equivalent.
Comment 2 Werner Lemberg 2016-05-29 23:59:49 UTC
Thanks for the quick reply.

I was imprecise, sorry; I've meant embedding a CFF stream in the PS file, of course.
Comment 3 Chris Liddell (chrisl) 2016-05-30 00:32:50 UTC
(In reply to Werner Lemberg from comment #2)
> Thanks for the quick reply.
> 
> I was imprecise, sorry; I've meant embedding a CFF stream in the PS file, of
> course.

Maybe I misunderstood then, but, from a Postscript job, we'll never get an OTTO nor OTC (nor TTC). If we get a Truetype it will be wrapped up as a Type 42. If a font started out as an OTTO or OTC, what will be embedded in the Postscript is the CFF stream wrapped in a Type 2 font.


If you're pondering whether to extend Freetype's Type 42 support to support something other that TrueType outlines, then the answer is "no" - a Type 42 with something other than TTF outlines is invalid.

(Note that the way the Ghostscript/Freetype integration works, Freetype never sees a Type 42 from us: what we pass to Freetype is a Truetype.)


And I certainly do plan to extend/improve our support of OTTO/OTC/TTC files, but heaven knows when I'll have the time....... but because of the way we have to load such fonts, Freetype will still only ever see Truetype or CFF fonts derived from those inputs.
Comment 4 Chris Liddell (chrisl) 2016-06-03 03:50:27 UTC
Werner,

Are you happy with the information here? Or do you need/want more from us?

In other words, can I close this bug?
Comment 5 Werner Lemberg 2016-06-03 12:37:07 UTC
Thanks!  Yes, I got all the information, so please close.
Comment 6 Chris Liddell (chrisl) 2016-06-03 15:38:29 UTC
(In reply to Werner Lemberg from comment #5)
> Thanks!  Yes, I got all the information, so please close.

Thanks.
Comment 7 Jungshik Shin 2016-09-16 10:37:44 UTC
(In reply to Chris Liddell (chrisl) from comment #3)

> And I certainly do plan to extend/improve our support of OTTO/OTC/TTC files,
> but heaven knows when I'll have the time....... but because of the way we
> have to load such fonts, Freetype will still only ever see Truetype or CFF
> fonts derived from those inputs.

Is there a bug filed against OTTO/OTC/TTC support for tracking this issue?  
If not, I'll file a new bug on that issue. 


I noticed that ghostscript is shipped with 'DroidSansFallback.ttf' as a CJK substitution font (that Android used to have but does not use any more). 

It'd be really nice if Noto Sans CJK ( https://www.google.com/get/noto/help/cjk/  https://github.com/googlei18n/noto-cjk ) can be used in ghostscript because they have a lot better support for CJK. Currently, it cannot be because Noto Sans CJK comes in OTF (with CFF) or OTC.
Comment 8 Chris Liddell (chrisl) 2016-09-16 13:31:17 UTC
It's probably covered by a combination of:
http://bugs.ghostscript.com/show_bug.cgi?id=690110

and

http://bugs.ghostscript.com/show_bug.cgi?id=695903