There may be an interest in fully embedding a font for PostScript
output. IIUC there may be a print manager that pre-processes PostScript
files, extracts embedded fonts to store them somewhere and re-use them
whenever needed. It can then strip the font off subsequent files and
substantially lighten them, speeding up the printing process.

What’s the purpose of the ‘encoding’ parameter? It looks to me like
users don’t care about what encoding is used in the PDF or PostScript
file. All they want to have is properly printed documents that use their
own fonts. I think that parameter should be removed in favour of Mehdi’s
proposal, which IMO makes much more sense from a user perspective.

Granted, there would be some redundancy with the referenced-fonts
element. But is the additional flexibility of regexp really useful in
the first place? I’m not too sure. Maybe that could be removed too.


On 09/11/10 12:45, Jeremias Maerki wrote:
> Hi Mehdi,
> I'm against that since we already have mechanisms to control some of
> these traits and this would overlap with them. For example, we have the
> referenced-fonts element
> (
> which controls whether we embed or not. And we have the encoding-mode
> attribute on the font element to control if single-byte or cid mode
> should be used. Granted, that's not exactly what you're after, but I
> believe this already covers 95% of the use cases if not more.
> The only thing you can't currently do is embed a full font in CID mode
> (or reference it). The problem here is the character map that should be
> used when in CID mode. I think that would require some research first so
> we know how best to handle this. For example, referencing only makes
> sense if a TrueType font can be installed directly on the printer. But
> then, the question is in which mode the characters can be addressed.
> Single-byte (like we currently fall back to) is probably not a problem
> unless you need to print Asian documents. Please note that we also don't
> support full TTF embedding/referencing in CID mode in PDF documents. So
> I'm not sure if we really need that at the moment.
> If we do, I believe it would generally suffice to extend encoding-mode
> from (auto|single-byte|cid) to (auto|single-byte|cid|cid-full). We may
> need a "cmap" parameter then to change the default CMap (currently
> "Identity-H" like in PDF) since our subsetting code uses custom mappings,
> not Unicode or any other encoding scheme (like "90ms-RKSJ-H").
> On 09.11.2010 12:08:36 mehdi houshmand wrote:
>> Hi,
>> I'm working on making TTF subset embedding configurable such that a
>> user can opt for either full font embedding, subset embedding or just
>> referencing, this would be extending the work Jeremias submitted. I
>> was considering adding a parameter to the font configuration file
>> called "embedding" with 3 possible values "none", "subset" and "full".
>> This would allow the user to configure the embedding mode on a font by
>> font basis. What do people think about this proposal?
>> Thanks
>> Mehdi
> Jeremias Maerki

Reply via email to