Thanks for your votes and testing the code. From reading the feedback I don't
think it would be the right option to simply modify and push it through as a
disabled by default feature and so will register Vincent's vote as a -1 and
look to address his and Luis's concerns.
Regarding one of the points Vincent made about the Postscript Parser, the
matter is complicated by the nature of the code being parsed. A traditional
method of parsing a file would be to scan for tokens (using maybe a String
Tokenizer) and then send those to the interpreter. Unfortunately Postscript
Type 1 fonts have a mixture of regular code and binary data (Subroutines /
CharString data). If a traditional Tokenizer were to be used the data would
inevitably become corrupted. The alternative I chose balances the need to keep
these sections intact and accessible whilst providing the means to parse tokens
and interpret them as part of an expandable solution. There may be other
solutions but any parser which would be written would need to do so on a byte
by byte basis as opposed to feeding it in and expecting a list of tokens. I am
going to leave the current implementation as it is but will look to address the
Bakoma font problem Luis found and perform more extensive testing with other
Type 1 fonts to try and prevent any further issues.
I will look to address the other issues you both raised in the coming weeks.
Thanks for your input.
Date: Mon, 17 Mar 2014 00:19:18 +0000
Subject: Re: [VOTE] Applying the Type 1 subset patch
I performed some further tests, still on Mac, but with a couple of
ghostscript type1 fonts, which are probably the same one finds in
The test was successful in that the output looked good (for the
record I has some unpredictable output between different runs
which I could not reliably reproduce so I attribute that to an
environment issue, maybe the .fop directory).
My example included characters not present in the font. Instead of
# for the missing glyph I got z (see example attached), which
probably is not intended (i.e., looks like a bug). I was also
expecting that Adobe would indicate that the fonts are subset but
it doesn't but this could be a wrong expectation (the subset file
is nevertheless considerably smaller -- 64KB versus 219 KB).
Finally I ran a simple performance test. With the patched code
(that produces subset) the time was 175 msecs. With the current
trunk 83 msecs.
So I think the suggestion that Vincent put forward to not make
subset the default for type1 makes sense for now. I think this
requires a new vote with a new patch.
On 3/12/14, 12:06 AM, Luis Bernardo wrote:
Since apparently Macs have no type1 fonts I had to look for some
and I tried the first one from
(cmb10) which gave a problem:
So it seems this needs to be tested with more fonts. But I will
test next in with the default Linux type1 fonts.
On 3/7/14, 11:23 AM, Robert wrote:
About a week ago I posted a patch to add Type 1 subset support
to FOP. All referenced Type 1 fonts (unless set to
embedding-mode="full") will now be subset by default much like
the behaviour exhibited by TrueType and OpenType. As this is a
big feature and quite involved I think it is necessary to vote
on whether to add this feature in it's current state to FOP.
I'm not sure if anyone has taken a look at what has gone into
this or tried it out yet, but it might be worth doing so
before making your decision.
I am going to be away for the next week or so but will tally
up the votes and post the result once I am back.
Here is a link to the patch and issue: