Yes... If you build it, it will be tested... ;-) I guess I was just
trying to identify the minimum PDF viewers FOP strives to support.

As for 'cleanup', you mentioned the PS & PDF code'll be messier but it
doesn't matter much... If it doesn't matter much (e.g., it's still
valid) then I guess we're good...

Clay



On 2/15/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> On 14.02.2008 16:24:40 The Web Maestro wrote:
> > In addition to Acrobat 6,7,8,+, Apple QuickView & Evince, I would
> > think nice to have:
> > - Acrobat Reader 5 (last version for Mac OS 9 Classic)
> > - Apple Preview 10.4 (probably similar to QuickView)
> > - Preview for 10.3 (Panther) would be nice too...
>
> People are allowed to test with all the PDF viewers they want. I have no
> Mac so I can't test any of these.
>
> > Is it possible the PDF code for option 1 could be 'cleaned up' in the
> > future (or does it matter)?
>
> Sorry, but I don't know what you mean. What's there to clean up?
>
> > Clay
> >
> >
> >
> > On 2/13/08, Jeremias Maerki <[EMAIL PROTECTED]> wrote:
> > > Just some details what each approach will produce:
> > >
> > > #1 produces a /CIDFontType0 CIDFont [1] and a /Type0 Composite Font
> > > referencing the former.
> > >
> > > #2 produces one or more /Type1 fonts.
> > >
> > > [1] for TrueType we produce a CIDFontType2 CIDFont and a /Type0
> > > Composite font for each TrueType font. OpenOffice produces one or more
> > > /TrueType fonts for each TrueType font.
> > >
> > > #1 would always generate a CID font for simplicity. What you propose is
> > > basically a "#2a", i.e. produce a /Type1 font if the document stays
> > > within the default encoding of the font. If additional characters are
> > > used FOP would switch to CID fonts instead of producing a /Type1 font.
> > > So this needs elements from #1 and #2. Possible and probably makes sense
> > > if CID fonts work in the first place. I like it.
> > >
> > > BTW, I just found out that I have to generate a ToUnicode CMap if a
> > > Type1 font doesn't use one of the encodings that are predefined in the
> > > PDF spec. So a little more work for me there.
> > >
> > > On 13.02.2008 11:57:34 Vincent Hennebert wrote:
> > > > Hi Jeremias,
> > > >
> > > > With solution #1, if I happen to use only the glyphs from the font
> that
> > > > are available in its default encoding, will the resulting PDF be the
> > > > same as in solution #2?
> > > > What I mean is, will feature-incomplete PDF readers be able to display
> > > > it? In which case this wouldn't be that bad.
> > > >
> > > > Anyway, solution #1 also looks cleaner to me, so go for it. If that
> > > > means that I'll have to create a RFE for my favourite PDF reader, then
> > > > I'll do it ;-)
> > > >
> > > > Vincent
> > > >
> > > >
> > > > Jeremias Maerki wrote:
> > > > > I've been asked to look into the possibility to support unusual
> > > > > encodings (like Cyrillic) with Type 1 fonts. Right now we only
> support
> > > > > WinAnsiEncoding (plus special handling for Symbol and ZapfDingbats).
> > > > >
> > > > > I already have an AFM parser. The AFM parser is the precondition to
> > > > > safely support non-standard encodings as only this file contains the
> > > > > glyph list of a font.
> > > > >
> > > > > I'm now on a good way to support non-WinAnsi encodings since I can
> now
> > > > > build CodePointMapping instances from an AFM file. I then have to
> teach
> > > > > the PDF and PS renderers to make use of these special encodings.
> > > > >
> > > > > That's step 1, but it will only make the font's native encoding
> > > > > available in FOP. The number of available glyphs for a Type 1 font
> will
> > > > > still remain under 255 (typicaly under 223 as the first 32 chars are
> > > > > usually not used). To support all glyphs of a Type 1 font we need
> more
> > > > > and I found two possible ways to pursue:
> > > > >
> > > > > 1. Treat Type 1 fonts as CID fonts.
> > > > >
> > > > > + Probably the cleaner approach.
> > > > > + All glyphs are supported under one single font (no font
> renderer-level
> > > > >   font switching required, see below)
> > > > > - Makes the generated PDF/PS code a little less readable but that's
> not
> > > > >   important.
> > > > >
> > > > > 2. Do something like OpenOffice when handling fonts with more than
> 255
> > > > > chars: Create multiple single-byte encodings which map to the same
> base
> > > > > font. This will require an 1:n relationship from font to char
> mapping
> > > > > which the renderers also have to handle. The first encoding will be
> > > > > equal to the font's default encoding (PDF calls that the "implicit
> base
> > > > > encoding"). The other encoding(s) will be built from the rest of the
> > > > > available characters. In the renderer it will be necessary to switch
> > > > > fonts from one character to another (not the same as switching from
> > > > > Helvetica to Symbol, i.e. not at FO level, but at renderer level).
> > > > >
> > > > > + Higher compatibility with PDF viewers which are not yet
> > > > >   feature-complete.
> > > > > + Keeps the generated PDF/PS code more readable (not important)
> > > > > - Switching between derived fonts (i.e. font with a common base font
> but
> > > > >   with special encodings) is necessary. SingleByteFont needs to be
> split
> > > > >   in two classes.
> > > > >
> > > > > An example: The "Baskerville Cyrillic" font contains 264
> > > > > characters/glyphs. The default encoding only contains 221
> characters. So
> > > > > 43 additional characters can be made available like this.
> > > > >
> > > > > I'm currently leaning towards CID fonts as it is probably the
> cleaner
> > > > > approach. Both solutions are probably pretty much the same in terms
> of
> > > > > effort. The CID approach will take more work in the PS renderer and
> the
> > > > > multi-encoding approach will make changes necessary in FOP's font
> > > > > library.
> > > > >
> > > > > If anyone has thoughts on this, I'd appreciate it. I'll finish the
> > > > > changes for supporting the default encodings and then finish the
> > > > > processing feedback stuff before I finish this here.
> > > > >
> > > > > Jeremias Maerki
> > > >
> > > >
> > > > --
> > > > Vincent Hennebert                            Anyware Technologies
> > > > http://people.apache.org/~vhennebert
> http://www.anyware-tech.com
> > > > Apache FOP Committer                         FOP
> Development/Consulting
> > >
> > >
> > >
> > >
> > > Jeremias Maerki
> > >
> > >
> >
> > --
> > Sent from Gmail for mobile | mobile.google.com
> >
> > Regards,
> >
> > The Web Maestro
> > --
> > <[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
> > My religion is simple. My religion is kindness.
> > - HH The 14th Dalai Lama of Tibet
>
>
>
>
> Jeremias Maerki
>
>

-- 
Sent from Gmail for mobile | mobile.google.com

Regards,

The Web Maestro
-- 
<[EMAIL PROTECTED]> - <http://homepage.mac.com/webmaestro/>
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet

Reply via email to