You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by "Peter B. West" <pb...@powerup.com.au> on 2004/03/15 00:27:35 UTC
Fonts and Document
Fops,
What is the current situation with font information? I notice that the
Document class now contains a lot of Font setup information, whilst a
comprehensive set of font classes exists in ...fonts. I want to
introduce font information into alt-design as compatibly as possible
with HEAD. What do I need?
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Fonts and Document
Posted by Jeremias Maerki <de...@greenmail.ch>.
(comments inline)
On 17.03.2004 04:53:46 Peter B. West wrote:
<snip/>
> > As you've seen the Document class is a central class in font handling.
> > It currently (not in my ideas) provides direct access to font metric
> > information and to the list of fonts actually used in a rendering run
> > (we don't always want to embedd them all). The setup of all fonts is
> > done in the FontSetup class where the base 14 fonts are defined.
> > Additionally, custom fonts are added there. But the custom fonts are
> > mostly renderer-dependant, so at the moment, some font setup also takes
> > place in PDFRenderer for example. See PDFRenderer.configure (which
> > can build custom font information using an Avalon Configuration object
> > using a helper method from FontSetup) and PrintRenderer.setupFontInfo
> > which actually triggers the font setup. The fonts get registered with
> > the Document object and subsequently is available to the layout engine.
>
> One of the complications is that Document wears so many hats. I see a
> Document object referred to by the variable fontInfo in one place, and
> by the variable foTreeControl in another. Document implements
> FOTreeControl, FOTreeListener and AreaTreeControl, so the foTreeControl
> variable looks deliberate, but the fontInfo may be a hangover. In any
> case, wouldn't it be clearer to have such functions realized in separate
> objects which are created and managed by Document?
I agree 100%. I don't particularly like the Document class right now.
I'm still dreaming of font source services and an Avalon container but I
don't see it happen in the near future.
> > Most font classes in the fonts package deal with the different font
> > formats (single byte und unicode, base und custom...). There's also a
> > difference in audience: The layout needs different information (metrics
> > in particular) than the renderers (primarily information for using and
> > embedding the font in the target format.
>
> This is my first close look at fonts, and I have browsed the
> java.awt.Font and java.awt.FontMetrics classes and the java.awt.font
> package. In itself, this bundle of interfaces and classes is complex,
> but the nub of it seems to be the 2D font classes. At first glance,
> there is a close connection between fonts, glyphs, strings, text
> attributes and line layout, all covered in these classes.
>
> I am wondering if we cannot use the Java model as a basis for FOP's line
> area layout API. The discussion in
> http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-fonts.html#wp66677
> contains a discussion of implementing a custom text layout mechanism to
> enable features like kerning and ligatures.
We probably could, but I'm stating again that the whole AWT thing has
its quirks and it has already grown over a few JDK versions. I'd rather
have a clean cut tailored to our need with adapters for AWT fonts (the
AWT font source) and a chance to support whatever fonts we want.
Especially for embedding fonts (an important feature), last time I
looked, AWT fonts did not provide the necessary infrastructure.
> My intention is to develop the initial alt-design layout using AWT
> rendering. I assumed that I could get usable testing output more
> quickly that way, without having to delve into PDF.
Good idea but I'd like to point out something: If you look at Batik's
Javadocs you'll see that there are several packages dealing with
extending AWT infrastructure in order to meet the projects needs. Maybe
we need to find out how we can profit from the Batik team's findings
concerning AWT. Maybe parts of Batik could be used to work around some
of AWT's problems when they show up. There it is again, the XML Graphics
umbrella.
Now, if you base your layout on AWT APIs and find out later that for PDF
and PS the infrastructure is not good enough, you'll have a problem but
I don't think that's dramatic. It shouldn't be all to hard to rewrite
the necessary parts then, to draw in a adapterish abstraction layer.
> My comments may
> simply be conditioned by that perception. I'm not talking about
> adopting 1.4 (and 1.5 when it is stable), but using the API model where
> it provides appropriate methods for laying out text. One implication of
> that would be a fairly intricate interaction between all the phases of
> FOP, involving the font details provided by the renderer.
>
> However, I recall that Hansuli Anderegg has been working along these
> lines for some time now.
Right, I've done some investigation myself in this area by creating
proof-of-concept JPS output handlers to create PDF and PS (using parts
of our transcoders, i.e. the Graphics2D implementations). However, I
still don't buy the idea, yet, as the way to go. With separate PDF and
PS renderers I have everything under control. More code, granted.
It would certainly be interesting to have both models and compare them
more closely. I have once looked at Hansuli's code which seemed to me a
modified copy of the AWT renderer which is not such a good thing to do.
It should be possible to reuse code as much as possible even if it means
changing the original AWT, sorry, Java2D renderer. But that's already
many months in the past. Now we can start on the green field. Maybe
Hansuli chimes in again and helps us go into this direction.
> Btw, what search keys should I use to recover details of your font model
> from the archive, assuming there are differences between your model and
> the wiki?
Interesting threads:
http://marc.theaimsgroup.com/?t=104209837400001&r=1&w=2
http://marc.theaimsgroup.com/?t=98099184600003&r=1&w=2
I think the Wiki holds most of my view of things. Victor added a lot of
additional content I was unfortunately never able to completely
follow-up on.
http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign
Jeremias Maerki
Re: Fonts and Document
Posted by "Peter B. West" <pb...@powerup.com.au>.
Jeremias,
See below...
Jeremias Maerki wrote:
> The font subsystem is still far from finished. It's still quite complex
> to understand, unnecessarily so IMO. My font source idea still need to
> be implemented... Let's see if I can pull together some connectors.
I agree that it is complex to understand.
> As you've seen the Document class is a central class in font handling.
> It currently (not in my ideas) provides direct access to font metric
> information and to the list of fonts actually used in a rendering run
> (we don't always want to embedd them all). The setup of all fonts is
> done in the FontSetup class where the base 14 fonts are defined.
> Additionally, custom fonts are added there. But the custom fonts are
> mostly renderer-dependant, so at the moment, some font setup also takes
> place in PDFRenderer for example. See PDFRenderer.configure (which
> can build custom font information using an Avalon Configuration object
> using a helper method from FontSetup) and PrintRenderer.setupFontInfo
> which actually triggers the font setup. The fonts get registered with
> the Document object and subsequently is available to the layout engine.
One of the complications is that Document wears so many hats. I see a
Document object referred to by the variable fontInfo in one place, and
by the variable foTreeControl in another. Document implements
FOTreeControl, FOTreeListener and AreaTreeControl, so the foTreeControl
variable looks deliberate, but the fontInfo may be a hangover. In any
case, wouldn't it be clearer to have such functions realized in separate
objects which are created and managed by Document?
> Most font classes in the fonts package deal with the different font
> formats (single byte und unicode, base und custom...). There's also a
> difference in audience: The layout needs different information (metrics
> in particular) than the renderers (primarily information for using and
> embedding the font in the target format.
This is my first close look at fonts, and I have browsed the
java.awt.Font and java.awt.FontMetrics classes and the java.awt.font
package. In itself, this bundle of interfaces and classes is complex,
but the nub of it seems to be the 2D font classes. At first glance,
there is a close connection between fonts, glyphs, strings, text
attributes and line layout, all covered in these classes.
I am wondering if we cannot use the Java model as a basis for FOP's line
area layout API. The discussion in
http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec/j2d-fonts.html#wp66677
contains a discussion of implementing a custom text layout mechanism to
enable features like kerning and ligatures.
My intention is to develop the initial alt-design layout using AWT
rendering. I assumed that I could get usable testing output more
quickly that way, without having to delve into PDF. My comments may
simply be conditioned by that perception. I'm not talking about
adopting 1.4 (and 1.5 when it is stable), but using the API model where
it provides appropriate methods for laying out text. One implication of
that would be a fairly intricate interaction between all the phases of
FOP, involving the font details provided by the renderer.
However, I recall that Hansuli Anderegg has been working along these
lines for some time now.
Btw, what search keys should I use to recover details of your font model
from the archive, assuming there are differences between your model and
the wiki?
Peter
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Fonts and Document
Posted by Jeremias Maerki <de...@greenmail.ch>.
The font subsystem is still far from finished. It's still quite complex
to understand, unnecessarily so IMO. My font source idea still need to
be implemented... Let's see if I can pull together some connectors.
As you've seen the Document class is a central class in font handling.
It currently (not in my ideas) provides direct access to font metric
information and to the list of fonts actually used in a rendering run
(we don't always want to embedd them all). The setup of all fonts is
done in the FontSetup class where the base 14 fonts are defined.
Additionally, custom fonts are added there. But the custom fonts are
mostly renderer-dependant, so at the moment, some font setup also takes
place in PDFRenderer for example. See PDFRenderer.configure (which
can build custom font information using an Avalon Configuration object
using a helper method from FontSetup) and PrintRenderer.setupFontInfo
which actually triggers the font setup. The fonts get registered with
the Document object and subsequently is available to the layout engine.
Most font classes in the fonts package deal with the different font
formats (single byte und unicode, base und custom...). There's also a
difference in audience: The layout needs different information (metrics
in particular) than the renderers (primarily information for using and
embedding the font in the target format.
Just a quick write-up, but I hope it still helps a bit.
On 15.03.2004 00:27:35 Peter B. West wrote:
> Fops,
>
> What is the current situation with font information? I notice that the
> Document class now contains a lot of Font setup information, whilst a
> comprehensive set of font classes exists in ...fonts. I want to
> introduce font information into alt-design as compatibly as possible
> with HEAD. What do I need?
Jeremias Maerki
Re: Fonts and Document
Posted by "Peter B. West" <pb...@powerup.com.au>.
Thanks Simon. Mozilla seems to have an issue with the xml PI at the
beginning of the xhtml form of the document. When I remove it, the page
is displayed correctly.
I'll get back to you when I have read the page.
Peter
Simon Pepping wrote:
> On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote:
>
>> I want to
>>introduce font information into alt-design as compatibly as possible
>>with HEAD. What do I need?
>
>
> I am completing my documentation on FOP code, see
> http://www.leverkruid.nl/FOP/index.html. I have a chapter on
> fonts. Maybe it helps you gain some quick insight.
--
Peter B. West <http://www.powerup.com.au/~pbwest/resume.html>
Re: Fonts and Document
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Mon, Mar 15, 2004 at 01:40:59PM -0800, Clay Leeds wrote:
>
> On Mar 15, 2004, at 1:15 PM, Simon Pepping wrote:
> Looks good, Simon... I don't suppose you could create a PDF version? (I
> know a great XML => PDF conversion tool. :-)) Seriously though, this
> looks like a great potential addition to the Developer documentation we
> have on the FOP site. BTW, it looks like everything after Chapter 2, #3
> is under <PRE> or <CODE> tags, so you've lost the formatting.
I am glad you like it. I do not see your problem after Chapter 2,
#3. In my browser, Mozilla and Mozilla FireBird viewing the local
file (i.e. not via a server), everything looks as I expect.
I will try this great conversion tool. If it can deal with the fo file
that is produced by the Docbook XSL style sheets, it should be
easy. You can try it yourself, because the DocBook XML file is also
available from my web site,
http://www.leverkruid.nl/FOP/documentation.xml.
I am currently converting my raw notes to DocBook XML, and in the
process rewrite those portions that do not seem good enough. I hope to
finish this in two to four weeks. I would be pleased to add it to the
developer documentation on the FOP web site if it is appreciated. I
wonder if DocBook XML is the right format for the web site. For me it
is the right format to write this kind of technical documentation.
Regards,
Simon Pepping
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: Fonts and Document
Posted by Clay Leeds <cl...@medata.com>.
On Mar 15, 2004, at 1:15 PM, Simon Pepping wrote:
> On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote:
>> Fops,
>>
>> What is the current situation with font information? I notice that
>> the
>> Document class now contains a lot of Font setup information, whilst a
>> comprehensive set of font classes exists in ...fonts. I want to
>> introduce font information into alt-design as compatibly as possible
>> with HEAD. What do I need?
>
> I am completing my documentation on FOP code, see
> http://www.leverkruid.nl/FOP/index.html. I have a chapter on
> fonts. Maybe it helps you gain some quick insight.
>
> Regards,
> Simon Pepping
>
> --
> Simon Pepping
> home page: http://www.leverkruid.nl
Looks good, Simon... I don't suppose you could create a PDF version? (I
know a great XML => PDF conversion tool. :-)) Seriously though, this
looks like a great potential addition to the Developer documentation we
have on the FOP site. BTW, it looks like everything after Chapter 2, #3
is under <PRE> or <CODE> tags, so you've lost the formatting.
Cheers!
Web Maestro Clay
Re: Fonts and Document
Posted by Simon Pepping <sp...@leverkruid.nl>.
On Mon, Mar 15, 2004 at 09:27:35AM +1000, Peter B. West wrote:
> Fops,
>
> What is the current situation with font information? I notice that the
> Document class now contains a lot of Font setup information, whilst a
> comprehensive set of font classes exists in ...fonts. I want to
> introduce font information into alt-design as compatibly as possible
> with HEAD. What do I need?
I am completing my documentation on FOP code, see
http://www.leverkruid.nl/FOP/index.html. I have a chapter on
fonts. Maybe it helps you gain some quick insight.
Regards,
Simon Pepping
--
Simon Pepping
home page: http://www.leverkruid.nl