Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
On 26.11.2003 21:32:30 J.Pietschmann wrote:
Victor Mote wrote:
Yes, this can get ugly. If anybody knows of a way to find the physical font
file from an awt Font object, please speak up.
Currently (as of 1.4.1 you can create a awt.Font from an InputStream, but
you cant get back whatever physical representation the font has from
the awt.Font object.
Javadoc tells me this works since 1.3 (Font.createFont method).
Anyway, it's the opposite of what Victor wanted.
I thought of the following approach
interface fop.font.Font {
public InputStream getFontInputStream();
public awt.Font getAWTFont();
// duplicate AWT methods, with certain stuff like metrics
// replaced with FOP objects
}
class fop.font.AWTFont implements fop.font.Font {
// delegate to AWT font
// encapsulate awt.FontMetric in FOP font metric
public InputStream getFontInputStream() { return null; }
}
class fop.font.Type1Font implements fop.font.Font {
public awt.Font getAWTFont() { return null;}
// use FOP type 1 font reader
}
class fop.font.TrueTypeFont implements fop.font.Font {
public awt.Font getAWTFont() { return new Font(new FileInputStream...);}
I think you meant return Font.createFont(Font.TRUETYPE_FONT, new
FileInputStream...
// use FOP TTF reader or delegate to the AWT font.
}
class fop.font.PDFBuiltinFont implements fop.font.Font {
public InputStream getFontInputStream() { return null; }
public awt.Font getAWTFont() { return null;}
// return generated classes for metrics etc.
}
This means users can use AWT fonts for creating PDF, but they can't
embed them. This may cause the resulting PDF to fail, but so what.
-- Support questions
And there's still the question if we can produce font metric information
for the target formats (there's PCL and PostScript and..., too) that
result in the desired output.
We *could* try to use the TTF reader to search through the fonts
in the Windows font directory (or XFonts) in order to find the
file for an AWT font.
Yeah, but it will be so slow. You'd need some persistent cache to
overcome that.
Seriously, I don't think working with AWT's Font will do us any good.
The differences between JDKs are too great.
We need java.awt.Font objects for the Java2D-related renderers, but
producing/getting these objects is the renderer's job, just as it's the
PDFRenderer's job to produce PDF font objects for serialization. IMO
it's better to have full control over what happens.
Jeremias Maerki
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Jeremias Maerki wrote: Anyway, it's the opposite of what Victor wanted. Yeah. I think you meant return Font.createFont(Font.TRUETYPE_FONT, new FileInputStream... OOps, yes. This means users can use AWT fonts for creating PDF, but they can't embed them. This may cause the resulting PDF to fail, but so what. -- Support questions It depends. If users are still required to declare used fonts explicitely as well as whether they should be embedded, and FOP bails out if told to embed an AWT font, it shouldn't be much of a problem. And there's still the question if we can produce font metric information for the target formats (there's PCL and PostScript and..., too) that result in the desired output. The idea was to query the renderer for fonts, or get a renderer specific font manager, and use the abstract interface to get mainly character metrics, various other font measures and perhaps font attributes like sans-serif or so. Seriously, I don't think working with AWT's Font will do us any good. The differences between JDKs are too great. Hmhm. I still think - We must be able to use AWT fonts in the AWT renderer. - We must be able to use the default PDF fonts for the PDF renderer - We should be able to use TTF for both AWT and PDF - We should not rely on the default PDF fonts in the AWT renderer (doh!) - I'd like to support using TTF with generated and possibly hand-corrected metrics as well as using TTF directly. The possiblity to use AWT fonts for non-embedded fonts in PDF is a bonus. The possiblity to use AWT fonts in PDF even for embedding would be just another bonus. J.Pietschmann
Re: Font variant SmallCaps
Peter B. West wrote: Although not mandated in XSL-FO, CSS2 offers a number of methods of font matching, only some of which preserve metrics. The FO User Agent is free to make implementation-specific decisions about this, I assume. My main interest here is in whether we want to try to separate out the font handling so that we try to guarantee identical layout on any renderer, or whether we state up front that such universality is *not* on offer. I don't think the TXT renderer will in general render to the same layout as others :-) Nitpicks aside, fonts may be renderer specific. If different renderers use an identical font (e.g. a user configured TTF) chances are that the layout is the same, provided bitmap images are rendered identically. If different renderers use different fonts, which may have different metrics even if they are the same family, the layout is likely to be different too. I can't see how to avoid this. BTW fonts aren't the only considerations, others are color and the discretization of coordinates (e.g. bitmap vs. vector format). I would assume that the most useful response to the above situation is to issue a warning and do one's best to match the font. The user has access to a number of mechanisms for narrowing font choice, and in the worst case we use a fall-back font. I'd say if the user saye font-family=futura, sans-serif,any he'll get a warning that a fallback was used in case there is no futura or not even a sans-serif font. If the user says font-family=futura and there is no futura font, FOP should terminate. After all, the user hopefully thought about it. J.Pietschmann
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
On 27.11.2003 17:30:18 J.Pietschmann wrote: Jeremias Maerki wrote: snip/ This means users can use AWT fonts for creating PDF, but they can't embed them. This may cause the resulting PDF to fail, but so what. -- Support questions It depends. If users are still required to declare used fonts explicitely as well as whether they should be embedded, and FOP bails out if told to embed an AWT font, it shouldn't be much of a problem. Font configuration should/will become easier. For TrueType and Type1 fonts this should just be a matter of specifying a list of directories in which to look for fonts. A cache is needed to speed up the inventory on startup. And there's still the question if we can produce font metric information for the target formats (there's PCL and PostScript and..., too) that result in the desired output. The idea was to query the renderer for fonts, or get a renderer specific font manager, and use the abstract interface to get mainly character metrics, various other font measures and perhaps font attributes like sans-serif or so. My idea is still different: Having several font sources and the renderers merely announce which font sources they support. That leaves to option open for later to enable multiple renderers simultaneously. Example: FontSource A: TrueType fonts FontSource B: Type 1 fonts FontSource C: AWT fonts FontSource D: Base14 fonts FontSource E: PCL base fonts (just a guess) PDF renderer supports: A, B, D (maybe C) PostScript renderer supports: A, B, D (maybe C) Java2D/AWT renderer supports: A and C PCL renderer: Probably A, E . Seriously, I don't think working with AWT's Font will do us any good. The differences between JDKs are too great. Hmhm. I still think - We must be able to use AWT fonts in the AWT renderer. - We must be able to use the default PDF fonts for the PDF renderer - We should be able to use TTF for both AWT and PDF - We should not rely on the default PDF fonts in the AWT renderer (doh!) - I'd like to support using TTF with generated and possibly hand-corrected metrics as well as using TTF directly. The possiblity to use AWT fonts for non-embedded fonts in PDF is a bonus. The possiblity to use AWT fonts in PDF even for embedding would be just another bonus. +1 to all 7 points. Should be doable with my aproach. Jeremias Maerki
Re: Font variant SmallCaps
J.Pietschmann wrote: Peter B. West wrote: Although not mandated in XSL-FO, CSS2 offers a number of methods of font matching, only some of which preserve metrics. The FO User Agent is free to make implementation-specific decisions about this, I assume. My main interest here is in whether we want to try to separate out the font handling so that we try to guarantee identical layout on any renderer, or whether we state up front that such universality is *not* on offer. I don't think the TXT renderer will in general render to the same layout as others :-) Nitpicks aside, fonts may be renderer specific. If different renderers use an identical font (e.g. a user configured TTF) chances are that the layout is the same, provided bitmap images are rendered identically. If different renderers use different fonts, which may have different metrics even if they are the same family, the layout is likely to be different too. I can't see how to avoid this. This was my original perception. (I hadn't even thought about the different rendering of images.) BTW fonts aren't the only considerations, others are color and the discretization of coordinates (e.g. bitmap vs. vector format). All of which leads me to the question of what, exactly, we are trying to isolate and amalgamate in the font system. We can't get away from renderer dependencies, so the target renderer is going to have to be accommodated before any atomic elements are introduced to the Area Tree. As I said, I haven't been closely following the fonts discussion, but I'm confused as to where it fits in the scheme of things, and what it is trying to achieve. ... I'd say if the user saye font-family=futura, sans-serif,any he'll get a warning that a fallback was used in case there is no futura or not even a sans-serif font. If the user says font-family=futura and there is no futura font, FOP should terminate. After all, the user hopefully thought about it. Makes sense. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Jeremias Maerki wrote: And there's still the question if we can produce font metric information for the target formats (there's PCL and PostScript and..., too) that result in the desired output. The idea was to query the renderer for fonts, or get a renderer specific font manager, and use the abstract interface to get mainly character metrics, various other font measures and perhaps font attributes like sans-serif or so. My idea is still different: Having several font sources and the renderers merely announce which font sources they support. That leaves to option open for later to enable multiple renderers simultaneously. Yes, this latter idea is closer to my view as well. Victor Mote
RE: Font variant SmallCaps
Peter B. West wrote: BTW fonts aren't the only considerations, others are color and the discretization of coordinates (e.g. bitmap vs. vector format). All of which leads me to the question of what, exactly, we are trying to isolate and amalgamate in the font system. We can't get away from renderer dependencies, so the target renderer is going to have to be accommodated before any atomic elements are introduced to the Area Tree. As I said, I haven't been closely following the fonts discussion, but I'm confused as to where it fits in the scheme of things, and what it is trying to achieve. I think what we are trying to do is to separate Font details from the Layout and Render processes as much as possible. Renderer dependencies need to drive font selection, but by the time the Layout or Render actually start to do their work, those issues should already be resolved. Your inquiries here have actually caused me to rethink Fonts a bit. My view of FOP's overall design (I apologize for brining this up again, but it is necessary to explain the point) is that we have a Session (Driver) which can have multiple Documents, each of which can have multiple RenderContexts, each of which can have multiple Renderers. (The RenderContext class exists only in my mind right now, as I have failed to get support for it -- however, much of the discussion in this thread revolves around that concept). Document controls the FOTree build, RenderContext controls the Layout/Area Tree, and the Renderers simply render the Area Tree. Now, my plan has been to have FOTree resolve to a Font object during parsing. However, it is clear to me that actual Font resolution has to go with the RenderContext concept. So, probably the FOTree needs to store more raw information (perhaps in an FOFont object) that the RenderContext can resolve into a Font during layout. The performance impact should be minimal, but I think the extra layer of abstraction is important. Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Jeremias Maerki wrote: Font configuration should/will become easier. For TrueType and Type1 fonts this should just be a matter of specifying a list of directories in which to look for fonts. A cache is needed to speed up the inventory on startup. Hmhm. Not bad. My idea is still different: Having several font sources and the renderers merely announce which font sources they support. That leaves to option open for later to enable multiple renderers simultaneously. I don't think enabling multiple simultaneous renderers is worth the trouble. If there are fonts producing a different metric for the same font, all you share is parsing the FO tree and some property refining. You have to provide for the case that generated areas can't be reused across renderers and, if there should be any advantage, also for cases where it is possible to share areas. This looks ... complex. Example: FontSource A: TrueType fonts FontSource B: Type 1 fonts FontSource C: AWT fonts FontSource D: Base14 fonts FontSource E: PCL base fonts (just a guess) PDF renderer supports: A, B, D (maybe C) PostScript renderer supports: A, B, D (maybe C) Java2D/AWT renderer supports: A and C PCL renderer: Probably A, E . You need - a class managing the fonts - inquire the supported font types from the renderer - match the renderer font types with the managed fonts I still think it would be easier to get a renderer specific font manager from the renderer, or get the fonts directly from the renderer. The font managers or the renderes can share code for general configuration, caching, font file management etc. by subclassing a common class or by delegation (especially in the second case). J.Pietschmann
Re: Font variant SmallCaps
Simon Pepping wrote: I have taken a look at the way this question is dealt with in LaTeX (TeX does not have the notion of font families, LaTeX does). Here the question what to use for small caps font is deferred to the font setup. The font definition tables must define a small caps font. If they do not do so, a fallback font is used; this should also be defined in the fd tables. If they fail to do that as well, the system uses its fallback font. Like FOP's layout, LaTeX only uses the font metrics. The renderer should locate the actual font. If such a font does not exist, but must be emulated, then this should indicated in the font system configuration for the renderers. For example, the fonts map for dvips has these lines, which I believe tell it how to generate a small caps font: pplr8rn Palatino-Roman .82 ExtendFont TeXBase1Encoding ReEncodeFont 8r.enc Correct me if I'm wrong here, but doesn't TeX have a full font system of it's own? Doesn't TeX guarantee to produce .dvi (device independent, I think) files? I assume it does this based on its own fonts and any METAFONT data. The matching of this .dvi to actual output is then the job of a dvi-? renderer. That is, there is a translation step between the dvi and the native input of the renderer, e.g. PDF, PS, H-P printer or X11. What's the intention for the FOP font system? Is FOP going to define a set of fonts and font metrics in its User Agent font database (as per CSS2)? Will this be defined with reference to the supported renderers (statically), the supported renderers and the fonts available on the system on which FOP is running (statically + dynamically), or by some other means. XSL-FO does not, AFAIT, expect the User Agent to support the degree of font matching specified in CSS2, even though the font model is based on CSS2. E.g. there is no capacity to specify a download src property. Users can't specify font characteristics to the same degree as in CSS2. I have always assumed that rendering consistency was not guaranteed by XSL-FO. I can't find any reference ATM to justify that. So my basic belief is that FOP should not know anything about this. It should all be configured in the font system. That is how the user imposes his choice of fonts. If a user renders a given .fo file on two different systems, using the same renderer (say, PDF), and specifies a font family (say, Baskerville) that does not exist on the first system, but does on the second, what result should be expected? Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Peter B. West wrote: I'm fuzzy with this stuff, but isn't renderer-context a new notion? What you are calling renderer-context was previously only associated with the renderer as such, wasn't it? I'm assuming that the renderer-context is something that amalgamates font metrics. Renderers share a context if, among other things, their fonts share common metrics. Is this what you mean? Yes, pretty much. I had pushed a bit to try to make render context one of the high-level control objects, with the idea that the Area Tree could be reused by additional renderers. Another idea on the AWT font issue is to allow the user to register the location of the AWT font just like they would any other font. This would be equivalent to saying use the AWT metrics for this font, but get the physical font from a certain file. The problem there is, of course, that you introduce another possible layer of errors (can find the AWT metrics but not the physical file, or vice versa), but I think that would be quite managable. Speaking of errors: can find the AWT metrics, but they don't match the metrics of the font file. Yes, this can get ugly. If anybody knows of a way to find the physical font file from an awt Font object, please speak up. That is the only correct solution to this problem. Victor Mote
RE: Font variant SmallCaps
Peter B. West wrote: What's the intention for the FOP font system? Is FOP going to define a set of fonts and font metrics in its User Agent font database (as per CSS2)? Will this be defined with reference to the supported renderers (statically), the supported renderers and the fonts available on the system on which FOP is running (statically + dynamically), or by some other means. XSL-FO does not, AFAIT, expect the User Agent to support the degree of font matching specified in CSS2, even though the font model is based on CSS2. E.g. there is no capacity to specify a download src property. Users can't specify font characteristics to the same degree as in CSS2. Basically, FOP uses both user-generated font metrics (static) and AWT fonts (dynamic). AWT fonts are not suitable for embedding, because the AWT system doesn't tell us how to get to the physical font file. What specifically are you seeing in CSS2 that XSL-FO doesn't have? I have always assumed that rendering consistency was not guaranteed by XSL-FO. I can't find any reference ATM to justify that. I think you are right. If the font ain't there, you can't use it. So my basic belief is that FOP should not know anything about this. It should all be configured in the font system. That is how the user imposes his choice of fonts. I missed this original comment made by Simon Pepping. If, by font system Simon means those fonts available through java's AWT system, this is unacceptable at the moment because these fonts cannot be embedded. Also, not all systems have the graphical environment that is required to use the AWT system. If a user renders a given .fo file on two different systems, using the same renderer (say, PDF), and specifies a font family (say, Baskerville) that does not exist on the first system, but does on the second, what result should be expected? I think either a fallback font should be used with a warning, or an abortive error. Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Victor Mote wrote:
Yes, this can get ugly. If anybody knows of a way to find the physical font
file from an awt Font object, please speak up.
Currently (as of 1.4.1 you can create a awt.Font from an InputStream, but
you cant get back whatever physical representation the font has from
the awt.Font object.
I thought of the following approach
interface fop.font.Font {
public InputStream getFontInputStream();
public awt.Font getAWTFont();
// duplicate AWT methods, with certain stuff like metrics
// replaced with FOP objects
}
class fop.font.AWTFont implements fop.font.Font {
// delegate to AWT font
// encapsulate awt.FontMetric in FOP font metric
public InputStream getFontInputStream() { return null; }
}
class fop.font.Type1Font implements fop.font.Font {
public awt.Font getAWTFont() { return null;}
// use FOP type 1 font reader
}
class fop.font.TrueTypeFont implements fop.font.Font {
public awt.Font getAWTFont() { return new Font(new FileInputStream...);}
// use FOP TTF reader or delegate to the AWT font.
}
class fop.font.PDFBuiltinFont implements fop.font.Font {
public InputStream getFontInputStream() { return null; }
public awt.Font getAWTFont() { return null;}
// return generated classes for metrics etc.
}
This means users can use AWT fonts for creating PDF, but they can't
embed them. This may cause the resulting PDF to fail, but so what.
We *could* try to use the TTF reader to search through the fonts
in the Windows font directory (or XFonts) in order to find the
file for an AWT font.
J.Pietschmann
Re: Font variant SmallCaps
Peter B. West wrote: If a user renders a given .fo file on two different systems, using the same renderer (say, PDF), and specifies a font family (say, Baskerville) that does not exist on the first system, but does on the second, what result should be expected? If the user specified a fallback, it is tried, otherwise I'd expect an error abort. What should be the alternative to the latter? Guessing the font characteristics and using a substitute font? J.Pietschmann
Re: Font variant SmallCaps
On Wed, Nov 26, 2003 at 08:21:33PM +1000, Peter B. West wrote: Simon Pepping wrote: I have taken a look at the way this question is dealt with in LaTeX (TeX does not have the notion of font families, LaTeX does). Here the question what to use for small caps font is deferred to the font setup. The font definition tables must define a small caps font. If they do not do so, a fallback font is used; this should also be defined in the fd tables. If they fail to do that as well, the system uses its fallback font. Like FOP's layout, LaTeX only uses the font metrics. The renderer should locate the actual font. If such a font does not exist, but must be emulated, then this should indicated in the font system configuration for the renderers. For example, the fonts map for dvips has these lines, which I believe tell it how to generate a small caps font: pplr8rn Palatino-Roman .82 ExtendFont TeXBase1Encoding ReEncodeFont 8r.enc Correct me if I'm wrong here, but doesn't TeX have a full font system of it's own? Doesn't TeX guarantee to produce .dvi (device independent, I think) files? I assume it does this based on its own fonts and any METAFONT data. The matching of this .dvi to actual output is then the job of a dvi-? renderer. That is, there is a translation step between the dvi and the native input of the renderer, e.g. PDF, PS, H-P printer or X11. TeX comes indeed with a font system of its own. Later type1 fonts have been made accessible to TeX, in addition to its own bitmapped fonts. But one can logically separate the layout system (the TeX program) and the font system. The procedure you describe above is correct. The dvi file is sort of equivalent to the area tree: It has all layout and font information in a format that can be used by renderers to generate output. What I tried to say is that the layout program is only satisfied if it finds the metric data of the font that the user requests. It does not do anything smart about missing fonts. It is the responsibility of the font system to do the smart things: provide the font requested, or provide a replacement font for it, or provide a general fallback for missing fonts. And it does so based on the information in its font configuration files. These do the translation from a font-family/shape/weight/size combination to an actual font file name. This is also the place to specify if a small caps font exists or should be mimicked by using a smaller font. That would be a major trick, as Chris already noted. The notion of a virtual font might help here. That is a font that consists of pointers to glyphs in other fonts. It has its own metric file, so that the layout system does not note any anomaly. Typographically minded users like to buy lots of fonts and add them to the system. The system is informed about this, and about its shortcomings and the replacement fonts, by additional font configuration files. In addition, one can instruct renderers to generate glyphs by certain manipulations on the glyphs of existing fonts, such as slanting, extending. But perhaps I assume too easily that ideas from TeX can be copied to FOP. So my basic belief is that FOP should not know anything about this. It should all be configured in the font system. That is how the user imposes his choice of fonts. If a user renders a given .fo file on two different systems, using the same renderer (say, PDF), and specifies a font family (say, Baskerville) that does not exist on the first system, but does on the second, what result should be expected? Traditionally that depends on the renderer. Some produce a fallback font family, e.g. PostScript viewers may use Courier. Others just fail. Regards, Simon Pepping -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl
Re: Font variant SmallCaps
J.Pietschmann wrote: Peter B. West wrote: If a user renders a given .fo file on two different systems, using the same renderer (say, PDF), and specifies a font family (say, Baskerville) that does not exist on the first system, but does on the second, what result should be expected? If the user specified a fallback, it is tried, otherwise I'd expect an error abort. What should be the alternative to the latter? Guessing the font characteristics and using a substitute font? Although not mandated in XSL-FO, CSS2 offers a number of methods of font matching, only some of which preserve metrics. The FO User Agent is free to make implementation-specific decisions about this, I assume. My main interest here is in whether we want to try to separate out the font handling so that we try to guarantee identical layout on any renderer, or whether we state up front that such universality is *not* on offer. The latter course is certainly easier. The former seems to involve a metrics-preserving font matching front-end to every renderer. But fonts is an area I'm not familiar with. I would assume that the most useful response to the above situation is to issue a warning and do one's best to match the font. The user has access to a number of mechanisms for narrowing font choice, and in the worst case we use a fall-back font. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: Task list Was: Re: Font variant SmallCaps
J.Pietschmann wrote: Chris Bowditch wrote: but my motivation is just to get something rather than nothing. You are bored? Oh! Thanks for the suggestions. I think you misunderstood though, I'm far from bored, my employers keep me busy. Just trying to help get layout unbroken. Some tasks: - Implement text-align-last - Implement text-align=justify - Fix table headers. - Fix content rectangle computation for background filling - Fix bottom borders (and perhaps other too) - implement region precedence - Implement background images for regions - Implement background image attachment - Implement relative positioning - implement multi column layout - fix footnotes for multi column layout Blimey even RenderX struggle with that one! snip/ Chris
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Victor Mote wrote: I am confused by the distinction that you make between fop.PDFFont and fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless it is a renderer-specific class for getting a Type1Font (for example) into the PDF output. But I think that should be a method in the Type1Font class. I have spent more time than I should have trying to figure out why fonts are (or were) renderer-specific. I may still be missing something important. (I *do* understand why they are renderer-context specific, i.e the difference between the AWT context and the others). I'm fuzzy with this stuff, but isn't renderer-context a new notion? What you are calling renderer-context was previously only associated with the renderer as such, wasn't it? I'm assuming that the renderer-context is something that amalgamates font metrics. Renderers share a context if, among other things, their fonts share common metrics. Is this what you mean? Another idea on the AWT font issue is to allow the user to register the location of the AWT font just like they would any other font. This would be equivalent to saying use the AWT metrics for this font, but get the physical font from a certain file. The problem there is, of course, that you introduce another possible layer of errors (can find the AWT metrics but not the physical file, or vice versa), but I think that would be quite managable. Speaking of errors: can find the AWT metrics, but they don't match the metrics of the font file. p -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
J.Pietschmann wrote: Victor Mote wrote: No. Courier-Bold-Italic would be the Typeface, Courier would be the TypefaceFamily. So my Font object that gets used by FOP would be Courier-Bold-Italic at 12 points. It has a parent Typeface, which represents the Courier-Bold font file and its contents. This typeface has a parent TypefaceFamily, which represents the Courier family, and knows how to find bold, italic, small-caps, etc. Typefaces which are related. So your font is the same as an java.awt.Font? Same general concept, except I think there is a separate class for font metrics in that system. If I can ever find a way to get to the physical file (or some representation of it) through java.awt.Font (for embedding), we would use it along with our other font scheme. Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Victor Mote wrote: Same general concept, except I think there is a separate class for font metrics in that system. If I can ever find a way to get to the physical file (or some representation of it) through java.awt.Font (for embedding), we would use it along with our other font scheme. I believe we should just define a fop.Font interface which is the same as awt.Font, then provide implementations fop.AWTFont, fop.PDFFont (well all the variations), fop.Type1Font etc. A configurable selector (an Avalon selector) could selcet them. This way people could use AWT fonts without a hassle, with the small disadvantage that they can't be embedded. Jeremias, as the resident font guru, what do you think? J.Pietscmann
RE: Font variant SmallCaps
Simon Pepping wrote: These days everybody uses scalable fonts, but in principle it is possible that Courier-Bold-Italic at 10 points is a different font than Courier-Bold-Italic at 20 points, with a different metric file and different glyphs. The canonical example being of course TeX, with e.g. cmr5, cmr6 etc. I assume that you are referring to bitmap fonts here. I don't think we have anything implemented for such fonts right now, but if we were to do so, I think the scheme remains the same as far as the rest of FOP is concerned. IOW, the relationship between Font, Typeface, and TypefaceFamily is intact. The Font object handles any peculiarities related to the particular point size, regardless of their source. Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
(disclaimer: Due to lack of time and a hardware failure, I haven't read everything, yet) I don't think we can rely on java.awt.Font. A FOP-defined Font interfaces is necessary to really make sure FOP gets what it need. What we came up with on the Wiki pretty much shows my ideas for the font support: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPFontSubsystemDesign Basic parts of that are: - Font metric providing interfaces to hide the various font sources (AWT, Type1, TrueType) (There's no PDFFont in my view) - Renderers announce which font sources they support - rendering run (Document) holds the available font sources subset. - Font adapters provided by the renderers that know how to register/use/put a particular font in the output. Since I have too little time to really participate ATM I can't care too much how it is done, i.e. with a Avalon selector or with something else. I failed to give Avalon in FOP a good enough punch. My only concern is the separation of font sources from the renderers, so that a uniform way of making fonts available in FOP is possible. I'm sorry that I can't be more of a help right now. I'd love to help, but have other priorities. On 22.11.2003 15:18:25 J.Pietschmann wrote: Victor Mote wrote: Same general concept, except I think there is a separate class for font metrics in that system. If I can ever find a way to get to the physical file (or some representation of it) through java.awt.Font (for embedding), we would use it along with our other font scheme. I believe we should just define a fop.Font interface which is the same as awt.Font, then provide implementations fop.AWTFont, fop.PDFFont (well all the variations), fop.Type1Font etc. A configurable selector (an Avalon selector) could selcet them. This way people could use AWT fonts without a hassle, with the small disadvantage that they can't be embedded. Jeremias, as the resident font guru, what do you think? Jeremias Märki
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
J.Pietschmann wrote: I believe we should just define a fop.Font interface which is the same as awt.Font, then provide implementations fop.AWTFont, fop.PDFFont (well all the variations), fop.Type1Font etc. A configurable selector (an Avalon selector) could selcet them. This way people could use AWT fonts without a hassle, with the small disadvantage that they can't be embedded. Jeremias, as the resident font guru, what do you think? I am confused by the distinction that you make between fop.PDFFont and fop.Type1Font. In my mind, there is no such concept as a fop.PDFFont, unless it is a renderer-specific class for getting a Type1Font (for example) into the PDF output. But I think that should be a method in the Type1Font class. I have spent more time than I should have trying to figure out why fonts are (or were) renderer-specific. I may still be missing something important. (I *do* understand why they are renderer-context specific, i.e the difference between the AWT context and the others). Another idea on the AWT font issue is to allow the user to register the location of the AWT font just like they would any other font. This would be equivalent to saying use the AWT metrics for this font, but get the physical font from a certain file. The problem there is, of course, that you introduce another possible layer of errors (can find the AWT metrics but not the physical file, or vice versa), but I think that would be quite managable. I think the approach that you are recommending is roughly what Jeremias has suggested for fonts in general, and which I can live with as long as we essentially make everything but the interface protected. I think you still need to have a third class that sits between awt.Font and fop.Font, because there is no way to tell awt.Font to implement the fop.Font interface. I favored a concrete class with a method that did the selection, which seemed cleaner to my mind, but I see the benefits to the other approach. Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
From: J.Pietschmann [EMAIL PROTECTED] I have done some investigation into emulating the Font-variant stuff in a similar way to the maintenance branch. Victor Mote wrote: Typeface roughly corresponds to what is contained in a ttf of pfa font file. Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this or rather typeface==font-family? I just added the fontVariant property to the font class (the private member already existed - so it felt right) I don't understand what you are saying here. If emulation is used, it should probably at least be logged. Alternatively, a config option could control whether this is allowed at all. But I don't follow at all what you are suggesting with the renderer using the font to control the emulation. How does layout get done at all then? And what is the advantage over simply establishing the emulation in the FO Tree itself? The layout gets the metric from a FOP font structure, and it doesn't have to know whether the font is a true small caps font or emulates it. During rendering, of course, emulation has to take effect. Well, on a secont thought there is not much difference from emulating small caps before layout. Of course it makes sense to log if small caps is emulated. I am just aiming to implement small-caps emulation at this stage. I realise it is not the ideal solution, but my motivation is just to get something rather than nothing. The emulation is by no means easy I have the code from the maintenance branch, but it cannot simply be copied. In order to emulate small-caps, the text area in question must be broken up whenever case changes. This involves changing TextLayoutManager.getNextBreakPoss code to detect this, thus creating break possibilities and changing something else possibly the TLM.addAreas to ensure areas are created for each BP whilst font-variant=small-caps Chris _ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Victor Mote wrote: Victor Mote wrote: Typeface roughly corresponds to what is contained in a ttf of pfa font file. Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this or rather typeface==font-family? No. Courier-Bold-Italic would be the Typeface, Courier would be the TypefaceFamily. So my Font object that gets used by FOP would be Courier-Bold-Italic at 12 points. It has a parent Typeface, which represents the Courier-Bold font file and its contents. This typeface has a parent Sorry--this should say Courier-Bold-Italic. Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Victor Mote wrote: No. Courier-Bold-Italic would be the Typeface, Courier would be the TypefaceFamily. So my Font object that gets used by FOP would be Courier-Bold-Italic at 12 points. It has a parent Typeface, which represents the Courier-Bold font file and its contents. This typeface has a parent TypefaceFamily, which represents the Courier family, and knows how to find bold, italic, small-caps, etc. Typefaces which are related. So your font is the same as an java.awt.Font? So, during FO Tree construction, when a small-caps font is requested by the source document, FOP tries to find the small-caps variant for the Typeface (by looking at the parent TypefaceFamily). If it exists, it assigns that. If not, it uses the regular variant with an emulation on the point size, and assigns that. Everything downstream just knows to use that Font, doesn't need to know why. It sounds like we agree on all of this. No problem. J.Pietschmann
Task list Was: Re: Font variant SmallCaps
Chris Bowditch wrote: but my motivation is just to get something rather than nothing. You are bored? Oh! Some tasks: - Implement text-align-last - Implement text-align=justify - Fix table headers. - Fix content rectangle computation for background filling - Fix bottom borders (and perhaps other too) - implement region precedence - Implement background images for regions - Implement background image attachment - Implement relative positioning - implement multi column layout - fix footnotes for multi column layout - implement space and border conditionality - implement keeps - implement last page master - implement space-start and -after for inline regions - implement UTR14 line breaking, including soft hyphens - fix hyphenation in general, perhaps include normalization - implement table row and column borders - implement BIDI - implement glyph selection from multiple fonts - implement before floats - implement side floats - implement table cells outside rows - implement inline-containers - implement reference-orientation - implement glyph shaping (arabic, explicit joiners) J.Pietschmann
Re: Font variant SmallCaps
I have taken a look at the way this question is dealt with in LaTeX (TeX does not have the notion of font families, LaTeX does). Here the question what to use for small caps font is deferred to the font setup. The font definition tables must define a small caps font. If they do not do so, a fallback font is used; this should also be defined in the fd tables. If they fail to do that as well, the system uses its fallback font. Like FOP's layout, LaTeX only uses the font metrics. The renderer should locate the actual font. If such a font does not exist, but must be emulated, then this should indicated in the font system configuration for the renderers. For example, the fonts map for dvips has these lines, which I believe tell it how to generate a small caps font: pplr8rn Palatino-Roman .82 ExtendFont TeXBase1Encoding ReEncodeFont 8r.enc So my basic belief is that FOP should not know anything about this. It should all be configured in the font system. That is how the user imposes his choice of fonts. With kind regards, Simon Pepping On Thu, Nov 20, 2003 at 09:22:41PM +0100, J.Pietschmann wrote: Victor Mote wrote: Typeface roughly corresponds to what is contained in a ttf of pfa font file. Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this or rather typeface==font-family? I don't understand what you are saying here. If emulation is used, it should probably at least be logged. Alternatively, a config option could control whether this is allowed at all. But I don't follow at all what you are suggesting with the renderer using the font to control the emulation. How does layout get done at all then? And what is the advantage over simply establishing the emulation in the FO Tree itself? The layout gets the metric from a FOP font structure, and it doesn't have to know whether the font is a true small caps font or emulates it. During rendering, of course, emulation has to take effect. Well, on a secont thought there is not much difference from emulating small caps before layout. Of course it makes sense to log if small caps is emulated. J.Pietschmann -- Simon Pepping email: [EMAIL PROTECTED] home page: http://www.leverkruid.nl
RE: Font variant SmallCaps Was: Re: (Chris) Re: Traits
J.Pietschmann wrote: (Still not making sense? If you need any more intermediate steps in understanding how getters and setters actually make things work, we're just a message away ;) ) Dunno. Let me elaborate. We have FO - FOP layout - FOP renderer - output Font variant SmallCaps can be implemented in several ways - Get a SmallCaps font and use it. The handling is the same as for bold and italic (or font-weight and font-style) - Emulate by uppercasing lowercase characters and set an 80% size font for them before the text is laid out (maintenance branch implementation) - pass the attribute into the renderer or into the output and let them care for themself The layout needs font metrics, therefore from the point of view of the layout the first and third option are the same. The interesting point is whether option 2 is implemented, somewhere in the pipeling before individual character widths are used (and, if necessary, character height), or whether the layout can get its metrics form a FOP Font structure (FontState or whatever it is called now). The new logic that I envision on Fonts (subject to Jeremias' approval especially, and everyone else's in general) makes a distinction between Typeface and Font. A Font is a Typeface rendered at a specific point size. A Typeface roughly corresponds to what is contained in a ttf of pfa font file. So when a Font object is tied to an object, it can handle both cases fine. The FO Tree logic that determines which font object to use will have to determine whether a true small-caps typeface exists for the TypefaceFamily, and act accordingly. But everything downstream from there can simply use the stored Font object. If the font approach is used, we need font variant to be a font attribute. I'm too lazy to check whether this is already in place. The maintenance code didn't have it. I don't think it is. The idea is to have a TypeFaceFamily object that knows the relationship between the variations of the Typeface (i.e. bold, italic, small-caps). So each Font belongs to a Typeface, which in turn belongs to a TypeFaceFamily. So referencing a parent TypeFaceFamily can determine whether there is a related small-caps Typeface. The advantage of this approach compared to the early emulation approach is that if a user has a true small caps font, he can use it more easily. For FOP, there is still the problem what to do if there is no appropriate font. Just bailing out might be an idea, but not necessarily a good one. An alternative would be to let the emulation happen under control of the font, in the renderer. This would need some hooks which don't exist yet, because the emulation must be able to insert the font size change into the output. I don't understand what you are saying here. If emulation is used, it should probably at least be logged. Alternatively, a config option could control whether this is allowed at all. But I don't follow at all what you are suggesting with the renderer using the font to control the emulation. How does layout get done at all then? And what is the advantage over simply establishing the emulation in the FO Tree itself? Now the questions is: how should the implementation look in HEAD? I personally like the font+late emulation approach. J.Pietschmann Victor Mote
Re: Font variant SmallCaps Was: Re: (Chris) Re: Traits
Victor Mote wrote: Typeface roughly corresponds to what is contained in a ttf of pfa font file. Hm hm. A TTF is typically Courier-bold-italic or so. Did you mean this or rather typeface==font-family? I don't understand what you are saying here. If emulation is used, it should probably at least be logged. Alternatively, a config option could control whether this is allowed at all. But I don't follow at all what you are suggesting with the renderer using the font to control the emulation. How does layout get done at all then? And what is the advantage over simply establishing the emulation in the FO Tree itself? The layout gets the metric from a FOP font structure, and it doesn't have to know whether the font is a true small caps font or emulates it. During rendering, of course, emulation has to take effect. Well, on a secont thought there is not much difference from emulating small caps before layout. Of course it makes sense to log if small caps is emulated. J.Pietschmann
