Fonts
I have been exploring the way fonts are handled by Java as part of setting up a Java layout engine and renderer. I have committed a new class - org.apache.fop.render.awt.fonts - as a first cut at a fonts database for this application. I will attach the class description to this email. The focus of the Fonts class is to provide the facilities required by the Recommendation. The Rec and the CSS2 spec talk about the User Agent having a database of known fonts, and the new class is a sketch of this requirement. The work is far from complete, but out of the WIP the lines of an interface for such a fonts database start to emerge, for me at least. The database must be able to match a font given family name style - normal, italic, oblique variant - normal, small-caps weight - normal, bold, lighter, bolder, 100 - 900 stretch - ultra-condensed - ultra-expanded size Java font handling can match on family name, style and size directly and, with the fonts commonly available, on variant, weight and stretch only by constructing virtual fonts. The database must be able to provide a complete set of selectors for each of the system-fonts caption, icon, menu, message-box, small-caption, status-bar. Given the scope for the User Agent here, Java font handling can manage this. The database must support the generic font families serif, sans-serif, monospace, cursive and fantasy. This requirement is both system and installation dependent, but serif, sans-serif and monospace are available as logical fonts in Java. Cursive and fantasy fonts support will depend on available fonts, but individual renderers can check for the availability of a number of fonts known to fall into these categories. I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer. This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF. Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry? I'll try attaching the Javadoc description from org.apache.fop.render.awt.Fonts, as the included HTML may cause problems otherwise. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html Java font selection is based on family names. It seems that Java handles font mapping something like this:br Given a set of physical fonts like, e.g., Arial, Java reports them as pre font face: Arial logical:Arial family:Arial PSName:ArialMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Cursiva logical:Arial Cursiva family:Arial PSName:Arial-ItalicMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Negreta logical:Arial Negreta family:Arial PSName:Arial-BoldMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM font face: Arial Negreta cursiva logical:Arial Negreta cursiva family:Arial PSName:Arial-BoldItalicMT Style: PLAIN FAMILY WEIGHT POSTURE SIZE TRANSFORM /pre There are other Arial forms, e.g. Arial Black and Arial Narrow, but they fall into different families, as indicated by the font name. java.awt.font.TextAttribute defines a number of TextAttribute constants, and querying a Font object via getAvailableAttributes() will provide an array of attributes available on the Font. pIt seems there is a common set available on both Type1 and TrueType fonts in 1.4.2; viz FAMILY, WEIGHT, POSTURE, SIZE and TRANSFORM. Note that style is reported as PLAIN on all fonts, irrespective of the actual style according to the font name. pSIZE works as one might expect. WEIGHT is supported directly only for the weights provided in the set of family fonts. In the case of Arial, only REGULAR and BOLD. The same is true of POSTURE: REGULAR and OBLIQUE. There seems to be room here to experiment with virtual fonts. A virtual Arial font might be constructed
Bug report for Fop [2004/05/23]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 635|Opn|Nor|2001-02-18|Doesn't support id= attribute in fo:page-sequence | | 953|Opn|Nor|2001-03-12|Incorrect hyperlinks area rendering in justified t| | 1063|New|Nor|2001-03-21|fop does not handle large fo files| | 1180|New|Maj|2001-04-02|Problem with monospaced font | | 1859|Opn|Min|2001-05-22|org.apache.fop.apps.Driver.reset() doesn't fully r| | 1998|New|Nor|2001-06-05|linefeed-treatment not understood | | 2150|Ass|Maj|2001-06-13|New page with a table-header but without any tabl| | 2475|Ass|Nor|2001-07-06|Borders don't appear to work in fo:table-row| | 2740|New|Maj|2001-07-23|multi-page tables sometimes render badly | | 2909|New|Maj|2001-07-30|Gradient render error | | 2964|Ass|Nor|2001-08-02|problems with height of cells in tables | | 2988|New|Maj|2001-08-03|0.19: list-item-label does not stick to list-item-| | 3044|Ass|Maj|2001-08-08|keep-together not functioning | | 3280|New|Nor|2001-08-27|PCL Renderer doesn't work | | 3305|Opn|Nor|2001-08-28|list-block overlapping footnote body | | 3497|New|Maj|2001-09-07|id already exists error when using span=all attr| | 3824|New|Blk|2001-09-25|MIF option with tables| | 4030|New|Nor|2001-10-08|IOException creating Postscript with graphics on S| | 4126|New|Nor|2001-10-12|FontState.width() returns pts instead of millipts | | 4226|New|Nor|2001-10-17|The orphans property doesn't seem to work | | 4388|New|Nor|2001-10-24|Nullpointer exception in the construction of new D| | 4415|New|Nor|2001-10-25|scaling=uniform does not work on images... | | 4510|New|Nor|2001-10-30|fo:inline common properties ignored? | | 4535|New|Maj|2001-10-31|PCL renderer 1.13 not rendering SVG | | 4767|New|Nor|2001-11-09|SVG text is distored in PDF output| | 5001|New|Nor|2001-11-21|content-width and content-height ignored? | | 5010|New|Enh|2001-11-21|Better error reporting needed | | 5047|Ass|Nor|2001-11-23|Dotted border style is not supported | | 5124|New|Maj|2001-11-27|fo:block-container is not rendered properly using | | 5335|Opn|Min|2001-12-10|Text with embedded CID fonts not retrievable from | | 5655|Ass|Nor|2002-01-02|text-decoration cannot take multiple values | | 6094|Opn|Maj|2002-01-29|0.20.3rc hangs in endless loop| | 6237|Opn|Nor|2002-02-05|#xFB01 (fi ligature) produces a sharp? | | 6305|New|Nor|2002-02-07|Using fo:table-and-caption results in empty output| | 6427|New|Enh|2002-02-13|Adding additional Type 1 fonts problem| | 6437|New|Maj|2002-02-13|Tables without fo:table-column don't render | | 6483|New|Nor|2002-02-15|Table, Loop, footer could not fit on page, moving| | 6844|New|Nor|2002-03-04|No line breaks inserted in list-item-label| | 6918|New|Enh|2002-03-06|reference-orientation has no effect | | 6929|New|Nor|2002-03-06|Cells border hidden by cells background | | 6997|New|Nor|2002-03-09|[PATCH] Row-spanned row data breaks over a page wi| | 7140|New|Enh|2002-03-15|page-position attribute set to last on condition| | 7241|New|Nor|2002-03-19|keep-with-previous, keep-with-next only working on| | 7283|New|Nor|2002-03-20|Table border misaligned when using margin-left in | | 7337|New|Nor|2002-03-21|border around external image leaves empty space | | 7487|New|Nor|2002-03-26|break-before=page for table inserts empty page | | 7496|New|Nor|2002-03-26|The table header borders are not adjusted to the b| | 7525|New|Cri|2002-03-27|table with spans inside a list-block | | 7919|New|Cri|2002-04-10|problem to use attribute linefeed-treatment and li| | 8003|Ass|Maj|2002-04-12|FopImageFactory never releases cached images | | 8050|New|Nor|2002-04-13|Soft hyphen (shy;) is not handled properly | |
Re: Fonts
(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of
my current work with Java fonts. I'm afraid that I am still convinced
that font handling is properly the preserve of the renderers. The
layout engine needs only the font metrics, even for Java-based
layout. As far as layout is concerned, the glyphs could all be
Wingdings, as long as the metrics are right. The other required
information is that relating to font selection, as discussed above.
The logical home for font selection information is the renderer.
I see no problem with this. Ideally, anything renderer-specific,
including fonts, should be in the appropriate fop.render.{rendertype}
package.
This is not to say that, once a clean fonts interface has been
developed and implemented in all of the renderers, a further level of
abstraction cannot be applied to bring all of the information under
one umbrella. However, consider the problem of creating a new
renderer. Fonts are inherently renderer specific. It may be that
those fonts are shared between more that one renderer, but that fact
is incidental to, e.g., the common ancestry of PS and PDF.
If any render type relies on the fonts of another render type (e.g. PS
using PDF), we can have it import or subclass the font libraries of that
render type. (E.g. render.ps. code would import, say,
render.pdf.font.xxx classes.) The dependencies are better
self-documenting that way, IMO.
Which is more sensible - writing a renderer's font handling to a
common renderer font interface as an integral part of the renderer
implementation, or discovering the fonts quirks of this particular
renderer and adding them separately to a central font handler/registry?
The latter is outside my scope of knowledge (but sounds messy ;)--as for
the former, what font-specific methods (and their signatures) do you see
us needing to add to our render.Render interface (which declares the
minimal methods needed by layout to interact with a renderer)?
getFontMetrics()? isFontSupported()? (Currently, there is just a
setupFontInfo() in this interface, which, as you say, seems
nonideal--layout feeding the renderers the FontInfo.)
Thanks,
Glen
DO NOT REPLY [Bug 29025] - Document/LayoutStrategy consolidation
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29025. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29025 Document/LayoutStrategy consolidation [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED
DO NOT REPLY [Bug 27150] - FOP does not formatting xml to pdf in Jetspeed/Applet, but it works in Java application
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=27150. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=27150 FOP does not formatting xml to pdf in Jetspeed/Applet, but it works in Java application [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2004-05-23 18:30 --- Q But it only works in Java application and not in an java applet or in Jetspeed portlet. I hope you can help me with a solution by this problem. /Q For applets: FOP works as a Java application, so will work with Servlets (and should also with applets, providing the files can be both accessed and written to.) (http://xml.apache.org/fop/servlets.html). This appears to a question better placed on FOP-USER. IIRC the Xalan project has a sample Xalan Applet that can possibly/probably be customized to use FOP--but we don't get many requests at all for that. As for Jetspeed, we don't do anything with that product--like Cocoon, they interface with us, not vice-versa. If you're having problems getting Jetspeed to work with FOP--that is something to ask on their user lists, and, if Jetspeed does not support FOP, then either switch to a product that does or enter an enhancement request *on Jetspeed* to get their product to support FOP. As long as FOP works in a Java application, our part of the job is done--we don't code for our consumer applications, they code for us. xerces -- xalan -- fop -- cocoon, jetspeed(?) Thanks, Glen
Re: [Bug 29124] New: - New line breaking algorithm
Hi Luca, On Thu, May 20, 2004 at 03:30:13PM -, [EMAIL PROTECTED] wrote: Ok, so here is the patch I was talking about in the fop-dev mailing list. This is a strong and careful piece of work. Some implementation notes: 1) In order to minimize changes in other files, the LLM interacts with the TLM calling brand new methods that I added to the LayoutManager interface, providing null implementation in the AbstractLayoutManager. I also added a KnuthPossPosIter, which is almost a clone of BreakPossPosIter. I think a much more elegant solution would be having the LLM call getNextBreakPoss, and casting the returned object to KnuthElement. Maybe BreakPoss and KnuthElement could be subclasses of a same class, abstract, containing only a Position object and the method to access it: BreakPoss (same name, but a different class) | --- | | KnuthElementTheClassPreviouslyKnownAsBreakPoss All LM call getNextBreakPoss, but the LLM casts to KnuthElement and the other LM cast to TheClassPreviouslyKnownAsBreakPoss I would prefer the more elegant solution. Your comment: // QUESTION: maybe LayoutContext holds the Properties which // come from block-level? Answer: LayoutContext is the vehicle to pass data from one LM to its child LMs. The LLM tries the first time to find breaking point without word hyphenation; only if it doesn't find a set of break points, it calls again the algorithm after having hyphenated all words, so this patch includes the ones concerning hyphenation (bug 27773) and hyphenation of word with punctuation marks (bug 28431). I would have applied them (as amended by myself) if I would have had karma. I tried to use the old information (about the whole words) as much as possible, but I don't know whether this saves some time or it is just an unneeded complication. findHyphenationPoints(Paragraph currPar) seems to be a fairly complicated piece of code. Would it not be easier to rebuild the paragraph from scratch, this time with hyphenation? The existing method AbstractLayoutManager.reset(Position pos) could be used to reset the childLMs and the iterator over them. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
missing karma (was: Re: [Bug 29124] New: - New line breaking algorithm)
Simon, I've just sent a note about that. I hope you (and Clay) will have karma soon. It seems to have been forgotten. I don't think I have the necessary powers to add karma myself. Even if I had I wouldn't know what to do. By now I know a lot about Subversion, but still almost nothing about CVS (on the server). I'm sorry that it went wrong. On 23.05.2004 21:15:12 Simon Pepping wrote: I would have applied them (as amended by myself) if I would have had karma. Jeremias Maerki
Re: Fonts
Glen Mazza wrote:
(Far from being an expert on fonts, but commenting anyway... ;)
Peter B. West wrote:
I have read again the Wiki page on the font subsystem in the light of
my current work with Java fonts. I'm afraid that I am still convinced
that font handling is properly the preserve of the renderers. The
layout engine needs only the font metrics, even for Java-based
layout. As far as layout is concerned, the glyphs could all be
Wingdings, as long as the metrics are right. The other required
information is that relating to font selection, as discussed above.
The logical home for font selection information is the renderer.
I see no problem with this. Ideally, anything renderer-specific,
including fonts, should be in the appropriate fop.render.{rendertype}
package.
This is not to say that, once a clean fonts interface has been
developed and implemented in all of the renderers, a further level of
abstraction cannot be applied to bring all of the information under
one umbrella. However, consider the problem of creating a new
renderer. Fonts are inherently renderer specific. It may be that
those fonts are shared between more that one renderer, but that fact
is incidental to, e.g., the common ancestry of PS and PDF.
If any render type relies on the fonts of another render type (e.g. PS
using PDF), we can have it import or subclass the font libraries of that
render type. (E.g. render.ps. code would import, say,
render.pdf.font.xxx classes.) The dependencies are better
self-documenting that way, IMO.
This seems to be the pivot around which both approaches can coalesce.
As I look at this for longer, I see that my initial notions about the
requirement for fonts are compatible with the generics that Jeremias and
Victor are working towards. Those are, it seems to me, a set of
handlers for different types of Fonts - Type 1, TrueType, OpenType,
Metafont, Framemaker fonts, whatever.
Which is more sensible - writing a renderer's font handling to a
common renderer font interface as an integral part of the renderer
implementation, or discovering the fonts quirks of this particular
renderer and adding them separately to a central font handler/registry?
The latter is outside my scope of knowledge (but sounds messy ;)--as for
the former, what font-specific methods (and their signatures) do you see
us needing to add to our render.Render interface (which declares the
minimal methods needed by layout to interact with a renderer)?
getFontMetrics()? isFontSupported()? (Currently, there is just a
setupFontInfo() in this interface, which, as you say, seems
nonideal--layout feeding the renderers the FontInfo.)
At the moment, I don't see any font-specific methods required. The
basic methods are
FopFont getFont(String family, enum style, enum variant, enum
weight, enum stretch, float size, enum selectionStrategy);
FopFont getGenericFont(enum type. enum style, enum variant,
enum weight, enum stretch, float size);
FopFont getSystemFont(enum type);
where enum is probably an int in all cases. selectionStrategy
determines whether, e.g., intelligent font substitution occurs if the
family doesn't have an exact match.
Individual renderers would access their own databases of available
fonts, and make their own decisions about what comprises a generic font,
what comprises a system font, and how to build virtual fonts if
necessary. This functionality within the renderers could be built on
top of the Type1, TrueType, etc. versions of FopFont. However,
individual renderers may need to vary the outcomes. For example, PDF,
although it uses Type1 and TrueType fonts, needs to express them
somewhat differently. Consider that a throw-away comment; I don't know
how PDF uses these font types.
Take the Java renderer. By including appendedfontpath in a new or
modified font.properties file, I can add new Type 1 or TrueType fonts to
the JVM. Let's say I find a Garamond font when I start up. Does it
qualify as a serif font? As a fantasy font? That sort of information
can be built into the relevant underlying font handler, but I can see
that individual renderers might want to override some methods in order
to make their own Quality Of Service decisions. See the Note under
auto in 7.8.3 font-selection-strategy in the 1.1 Draft.
What I have said qualifies as a central font registry in a loose
sense, which may be refined later. E.g., QoS information may
progressively be moved into the underlying font type handlers. However,
it seems to me that the final decision is with the renderer, and it is
the renderer that should be queried when the FO tree is being built and
fonts resolved.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Fonts
Peter B. West wrote: I have been exploring the way fonts are handled by Java as part of setting up a Java layout engine and renderer. I have committed a new class - org.apache.fop.render.awt.fonts - as a first cut at a fonts database for this application. I will attach the class description to this email. The last time I checked, there was no way to get to the physical font file through the awt interface. It is possible that java.awt.font.OpenType can provide some or all of what is needed for TTF and OT fonts, but I don't know of a way to handle Type1 embedding at all. This means that you cannot ever embed the said font, unless you set up a parallel system (similar to the way FOP handles things now) to find the physical file. Another issue is headless environments. I once went down the path of trying to figure out how to register fonts in a headless environment, and frankly don't remember what I learned. It is probably possible. There may come a time when the awt system is the way to go, but AFAICT, it isn't here yet, but I'll be glad to be proven wrong. I don't say this to discourage you -- if you know how to make it work, that will be a very good thing. BTW, Hansuli Anderegg has been a frequent advocate of the awt system for this work. One important point here is that, even if awt font handling were the correct *implementation* of font handling to use, there would still be, IMO anyway, utility in hiding even that fact from the rest of FOP, certainly no harm. I am taking the next comment out of sequence from Peter's original post, because it is fundamental to comments earlier in his post, which I will address below: Fonts are inherently renderer specific. It may be that those No. Font *embedding* is renderer specific. AFAICT, everything else about the font is the same. I have read again the Wiki page on the font subsystem in the light of my current work with Java fonts. I'm afraid that I am still convinced that font handling is properly the preserve of the renderers. The layout engine needs only the font metrics, even for Java-based layout. As far as layout is concerned, the glyphs could all be Wingdings, as long as the metrics are right. The other required information is that relating to font selection, as discussed above. The logical home for font selection information is the renderer. It is a non sequiter to say that layout needs only font metrics (which is true), and therefore the logical home for font selection information is the renderer. One thing that may be confusing you is the distinction that awt makes between java.awt.Font and java.awt.FontMetrics. There is only one constructor for FontMetrics: protected FontMetrics(Font font) Therefore, at a *logical* level, there is a one-to-one relationship between the two. At the physical file level there is also a strict one-to-one relationship between the two, when the metrics are separated at all. There is no need that I can see for FOP to treat the concepts of Font and FontMetric as two different things. Once a font object is stored in the FOTree that object should be able to return any metrics information about that font. This is not to say that, once a clean fonts interface has been developed and implemented in all of the renderers, a further level of abstraction cannot be applied to bring all of the information under one umbrella. I have always found that cleaning up the abstraction levels and interfaces (i.e. getting the big-picture stuff straight first) makes getting the details right easier as well, by isolating them. However, I won't quibble with you. However, consider the problem of creating a new renderer. Fonts are inherently renderer specific. It may be that those fonts are shared between more that one renderer, but that fact is incidental to, e.g., the common ancestry of PS and PDF. Which is more sensible - writing a renderer's font Again, the underlying font is the same whether you are rendering to PDF, Postscript, or anything else. Only the embedding would change. Please let me know if I have missed something. PDF. Which is more sensible - writing a renderer's font handling to a common renderer font interface as an integral part of the renderer implementation, or discovering the fonts quirks of this particular renderer and adding them separately to a central font handler/registry? This is a very good question, one that I have already pondered at some length. Again, I am thinking only of the process of embedding here. The first principle that I look to is that in either case, font embedding should be factored out of FOP. There is nothing about either font-handling or the creation of PDF files (or PostScript, or PCL, or whatever) that is FOP-specific. Assuming this, I would lean heavily toward placing the font-embedding logic in the output-specific library (i.e., put the PDF embedding logic into the pdf output library, instead of fonts), because not
