RE: Fonts

[arnd . beissner]

Victor Mote [EMAIL PROTECTED] wrote
on 25.05.2004 01:46:50:

 However, since these same fonts could also be used by the PostScript
 renderer, or the Print or AWT renderers (assuming that the pfb is
available
 as well), I don't see a need to duplicate their definitions, or metrics,
or
 anything for each one of these environments, which is what it sounds
like
 you might be suggesting.

Yes, but the base-14 fonts for example are not defined
for AWT renderers, since
*only* their metrics is publicly available. Still,
in the case of the 
base 14-fonts you can really argue that you want to
extend the PDF model of
(these fonts are always there). Just note that on
many systems you are out
of luck with - for example - the Zapf Dingbats fonts.

 It should be sufficient for the Renderer (or
 RenderContext) to tell what it is *capable* of doing, without having
to
 provide the actual detail. In the case of the Base-14 font metrics,
we can
 and should and do embed them within FOP itself.

In the case of an AFP renderer your model would suggest
to the formatter
that the 4 faces of Helvetica, Times Roman and Courier
are available which
they are not. At least, you would have to supply additional
information
so that the formatter could decide which of the standard
fonts is available
to which renderer.

 Why is this better than simply supplying the same font metrics at
a global
 level, and letting the Renderer or RenderContext tell what it is/is
not
 capable of processing? What would one get in return for giving up
that
 simplicity?

You would gain simplicity in another respect - you
would exactly know 
which font (and not only which *type* of font is available
to which
renderer or device (in the latter case, think about
output to different
printers from the same installation, which could have
a differing set of
device fonts).

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

RE: Fonts

[Victor Mote]

Arnd Beißner wrote:

Arnd
Yes, but the base-14 fonts for example are not defined for AWT
renderers, since 
*only* their metrics is publicly available. Still, in the case of
the 
base 14-fonts you can really argue that you want to extend the PDF
model of 
(these fonts are always there). Just note that on many systems you
are out 
of luck with - for example - the Zapf Dingbats fonts. 
/Arnd

Victor
I don’t work with the AWT renderer, but it *should* be able to use the
base-14 fonts, assuming that the user has installed the font (not just the
metrics) on their system. It is true that only the metrics for base-14 fonts
are *freely* available, but the outlines *can* be licensed. In fact, I am
pretty sure they are all included in Adobe's Type1 version of its Type
Basics:
http://www.adobe.com/type/browser/P/P_934.jhtml

Your point is well taken that not all fonts are usable everywhere, but I do
like the idea of letting the *user* decide what those limitations are. For
example, in the example you gave of the device using bitmapped fonts, a user
might want to build PDF files at client machines that get queued up for a
machine that drives the printer itself. I think it is a good thing for
them to be able to do this. It is true that the view from within Acrobat
Reader is going to look different from the printed output, but I want to be
careful about artificially limiting the possibilities.
/Victor

Arnd
  Victor
 It should be sufficient for the Renderer (or
 RenderContext) to tell what it is *capable* of doing, without
having to
 provide the actual detail. In the case of the Base-14 font
metrics, we can
 and should and do embed them within FOP itself.
  /Victor

In the case of an AFP renderer your model would suggest to the
formatter 
that the 4 faces of Helvetica, Times Roman and Courier are available
which 
they are not. At least, you would have to supply additional
information 
so that the formatter could decide which of the standard fonts is
available 
to which renderer. 

  Victor
 Why is this better than simply supplying the same font metrics at
a global
 level, and letting the Renderer or RenderContext tell what it
is/is not
 capable of processing? What would one get in return for giving up
that
 simplicity?
  /Victor

You would gain simplicity in another respect - you would exactly
know 
which font (and not only which *type* of font is available to which 
renderer or device (in the latter case, think about output to
different 
printers from the same installation, which could have a differing
set of 
device fonts). 
/Arnd  

OK, but doesn't this mean that now the user has to write a subclass of some
Renderer in order to manage his fonts? It seems like a lot of this can be
handled in the font configuration side of things, which allows it to be more
easily accessible by the user.

In the example you give, the worst case scenario is that the AFP device gets
a document it can't handle or that looks awful when it is output. It is
totally within the user's ability to prevent and correct this. So really
what we are talking about is how to prevent the user from doing something
stupid. Even this can be prevented by forcing the user to use a font
configuration that only contains the fonts available.

Nevertheless, I have no objection in principle to giving the Renderer this
level of control if it needs or wants it. Here is what I propose -- the
forayFont API design has an interface for a FontConsumer, which the client
application must supply when it is accessing font services. We'll just add a
method, something like:
boolean canProcessFontFamily(String fontFamily)
 /* or perhaps the following, which would allow
FontConsumer to query the Font in more detail
about itself before deciding */
boolean canProcessFont(Font font)  

The Renderer will need to simply respond false when a font is presented
that it doesn't know how to handle. The font system can then throw an
exception back to the client application saying that the Renderer has
rejected the font.

This would *allow*, but not really *require* a Renderer to manage fonts at
the level of detail that you envision. So most Renderers could simply:
boolean canProcessFont(Font font)  {
return true;
}

I have added some comments regarding this to the FontConsumer section:
http://foray.sourceforge.net/module/font/index.html#api-design

This seems to address both of the competing concerns:
* your major concern that the Renderer have more control
* my major concern that fonts and font logic be removed from the
Renderers

It also seems to have the advantage of allowing the font subsystem to pull
information out of the Renderer as needed rather than having the Renderer
push everything it knows to the font system. 

Re: Fonts

[Clay Leeds]

On May 24, 2004, at 8:57 AM, Victor Mote wrote:
Clay Leeds wrote:
On the subject of running headless, my experience has been to
pass it off to POSTSCRIPT--which, again in my
experience--runs fine headless.
Off the top of my head, I can't think of a reason that the PostScript
renderer would work and the PDF renderer not work. I run all of my 
stuff in
a headless environment to PDF, with no problems. If you can provide 
some
details here, I am very interested to identify any RenderContext
differences.

Victor Mote
Actually, we wanted to use '-print' but it was complicated by the 
'headless' problem on AIX, so we went to '-ps' (PostScript), and did a 
'cat %1 lpr' (approximation). Don't get me wrong (apologies if I gave 
that impression!)--PDF works well, unless we need SVG/Batik.

Web Maestro Clay

Re: Fonts

[Glen Mazza]

Peter B. West wrote:
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 wrote:
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.
(Still learning...)
But wouldn't we need to add some form of isFontSupported(fontName, ...) 
to the Renderer interface?  AFAICT, the XSL font-family property allows 
me to specify any font I want, so long as it is supported by the 
RenderType I chose.   So if I invent a new RenderType, say Glen Document 
Format (GDF), and invent a new font for it, Glen Font, 
isFontSupported(Glen Font) would return true for the -gdf output 
type and false for the -pdf output type.  Then, layout would use that 
boolean value to determine whether it needs to fall back to a 
backup/default font.

Also, (this point I'm less certain on) a getFontMetrics(fontName) of 
some sort would be needed so layout can determine how much space Mary 
had a Little Lamb would consume using my new font on the defined output 
type, correct?  getFontMetrics() could be centralized in one place 
instead of being renderer-specific, but if so we may need to handle the 
issue of multiple renderers possibly having the same name for a font 
type but different metrics/meanings for them.  (E.g., courier new 
having different sizes in awt than it would in pdf, or a render type 
short-circuiting a popular font that it doesn't support to a similar 
supported one with slightly different metrics.)

Thanks,
Glen

Re: Fonts

[Clay Leeds]

On May 23, 2004, at 5:32 PM, Victor Mote wrote:
Glen Mazza wrote:
(Far from being an expert on fonts, but commenting anyway...  ;)
Ahem... possibly even farther from being an expert on fonts... and 
commenting anyway ;-)

(mildly OT: BTW, nice to have you 'back' [EMAIL PROTECTED] hope 
to/glad we'll be hearing more from you in the future...)

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.
On the subject of running headless, my experience has been to pass it 
off to POSTSCRIPT--which, again in my experience--runs fine headless. 
Perhaps something can be 'learned' from that interaction? Maybe instead 
of basing the implementation on AWT, it might make sense to base it 
instead off of POSTSCRIPT. Alternatively, perhaps Type1 might 'require' 
postscript? Dunno... just a thought...

Web Maestro Clay

Re: Fonts

[Peter B. West]

Glen Mazza wrote:
Peter B. West wrote:
  I wrote:
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.
(Still learning...)
But wouldn't we need to add some form of isFontSupported(fontName, ...) 
to the Renderer interface?  AFAICT, the XSL font-family property allows 
me to specify any font I want, so long as it is supported by the 
RenderType I chose.   So if I invent a new RenderType, say Glen Document 
Format (GDF), and invent a new font for it, Glen Font, 
isFontSupported(Glen Font) would return true for the -gdf output 
type and false for the -pdf output type.  Then, layout would use that 
boolean value to determine whether it needs to fall back to a 
backup/default font.
That would be covered in the combination of getFont(...) and 
selectionStrategy.  If the selection strategy excludes intelligent font 
substitution, and the given font family is not available, return null. 
If intelligent substitution is allowed, then let the renderer select 
another font family.  It's worth reading the relevant parts of the Fonts 
section in the CSS2 spec for some insight into the recommended font 
selection strategy.  XSL-FO adds another twist through 
font-selection-strategy.

The font-family property returns a list, the idea being that a series of 
family-names or generic-names can be tried in sequence to resolve a 
font.  I'll have to read the CSS2 description again to determine exactly 
how .

Also, (this point I'm less certain on) a getFontMetrics(fontName) of 
some sort would be needed so layout can determine how much space Mary 
had a Little Lamb would consume using my new font on the defined output 
type, correct?  getFontMetrics() could be centralized in one place 
instead of being renderer-specific, but if so we may need to handle the 
issue of multiple renderers possibly having the same name for a font 
type but different metrics/meanings for them.  (E.g., courier new 
having different sizes in awt than it would in pdf, or a render type 
short-circuiting a popular font that it doesn't support to a similar 
supported one with slightly different metrics.)
The font metrics would be implicit in the Font (or FopFont) object 
returned from the renderer.  Having the renderers (explicitly or 
implicitly) returning the Font object ensures that the layout's notion 
of metrics is the same as that of the renderer.

Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

RE: Fonts

[Victor Mote]

Peter B. West wrote:

  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.
 
 What I'm exploring is the possibility of going in the 
 opposite direction.  That is, using the Interfaces and 
 Classes of java text layout as a model for FOP layout, even 
 if the implementation is FOP specific.  That way, when the 
 Java model *is* adequate for FOP's use, it is a trivial 
 matter.  The 2D model of text layout seems very powerful.

This is only opposite in the sense of how the abstraction works. Your
approach is pretty sound, and, assuming that you can solve the embedding
problem, has some merit. However, there is no reason that the isolated Font
logic can't use the awt objects that you are interested in to do the work
behind the interface that FOray is building (or something similar). By
isolating all of this code, you can have your cake and eat it too. You can
use awt if, when, and how much it really makes sense, and you can do all
kinds of other stuff as well for places where awt is inadequate. For
example, awt gives access to the OpenType tables, but really doesn't do
anything with them. FOray wants to use that information, and I assume that
FOP will eventually want to also. So, why limit yourself to awt? As I said
before, even if awt were perfect, there is still value in hiding it,
especially during a refactoring stage.

  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.
  
 
 Given a logical layout, the final result is determined by the 
 renderer's 
 notion of glyphs, their metrics and their relationships.  Is 
 this not so?

Yes, and the renderer gets that information from the Font, which is still
the same Font, and has no idea who is using it or why or how.

I don't deny that the concept I have described as RenderContext (you may
have been off-line when we discussed this about a year ago) may affect
layout. Those differences must be considered during layout (but the logic of
handling them should not be done by the layout classes). RenderContext
describes the capabilities that are available, presumably what fonts are
available in this context, but could also include other things (can't kern,
can't do letter-spacing, can't stretch text, etc). AFAICT, PDF and
PostScript use the same RenderContext, but if there are differences, then
they can each have their own. Once these capabilities are defined, they must
be considered as the FOTree is built, and as layout is performed.

So, while the Font is always a constant, it needs to be filtered through
the lens of the RenderContext before it can be used properly. That is
probably why the Font stuff ended up in the Render classes. And that is
(part of) why I think, as FOP grows up here, it is important to distinguish
between the Renderer and the RenderContext.

If you'll give me a few weeks, I hope to be able to show you what I seem
unable to sell with words.

Victor Mote

RE: Fonts

[Victor Mote]

Clay Leeds wrote:

 On the subject of running headless, my experience has been to 
 pass it off to POSTSCRIPT--which, again in my 
 experience--runs fine headless. 

Off the top of my head, I can't think of a reason that the PostScript
renderer would work and the PDF renderer not work. I run all of my stuff in
a headless environment to PDF, with no problems. If you can provide some
details here, I am very interested to identify any RenderContext
differences.

Victor Mote

RE: Fonts

[Victor Mote]

Arnd Beißner wrote:

 To all of that I entirely agree, but might want to add one 
 thing: a renderer should have a way to supply a font to the 
 formatter's font repository. 
 This
 is needed when, for example, a print renderer can query and 
 use builtin printer fonts. The way to query and get these 
 (even if it's only a metrics-only
 font) should be in the renderer, though. Sometimes, this is 
 an essential feature, for example for special OCR/OMR fonts 
 stored in printers for which you may not have a screen font.

One of the changes that will probably need to be made to FOP's font handling
is to parse AFM files instead of PFMs. I have assumed that for hardware
fonts, either the device manufacturer provides font metrics files or enough
information so that they can be built. Adobe, for example, provides metrics
for the base-35 PostScript device fonts here:
ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/

So my *plan* has been that these fonts get treated pretty much like any
other font. The only thing about the hardware font is that it can't be
embedded -- it is already embedded all of the places that it can be.

Are you suggesting that FOP / FOray needs to actually query the hardware
device and extract metrics information directly from it? Or is the plan I
have outlined above sufficient?

Victor Mote

Re: Fonts

[Clay Leeds]

On May 24, 2004, at 5:16 AM, Jeremias Maerki wrote:
One big problem: As soon as you use SVG, you're running Batik code 
which
makes heavy use of AWT. I think with three different approaches to 
solve
the headless problem this shouldn't be a big issue, even on AIX, right?
We punted on the Batik side of things... We don't use it at all (at 
least as far as I can tell). As far as AWT goes (which we are having to 
use to implement TIF output--I may have something to offer in the 
not-too-distant future in that regard), we've been able to implement a 
pass-thru of sorts, essentially tricking AIX 'video' to /dev/null.

Hopefully, as you suggest, one of the three will work. Problem is, when 
the method you require has problems running headless (e.g., using AWT 
to output to TIF).

Web Maestro Clay

RE: Fonts

[arnd . beissner]

Victor Mote [EMAIL PROTECTED] wrote on 24.05.2004 18:12:36:

 One of the changes that will probably need to be made to FOP's font 
handling
 is to parse AFM files instead of PFMs. I have assumed that for hardware
 fonts, either the device manufacturer provides font metrics files or 
enough
 information so that they can be built. Adobe, for example, provides 
metrics
 for the base-35 PostScript device fonts here:
 ftp://ftp.adobe.com/pub/adobe/type/win/all/afmfiles/base35/

This is what did in my formatter. I have implemented an AFM reader (though 
I
ignore the kerning infos so far) and use this to read the Adobe base fonts 

- for example.
 
 So my *plan* has been that these fonts get treated pretty much like any
 other font. The only thing about the hardware font is that it can't be
 embedded -- it is already embedded all of the places that it can be.

Depends. Every PDF compliant reader/printer has to support 
Adobe's standard Helvetica, Times Roman, Courier, Symbol and Zapf Dingbats
fonts (metrics-compatible alternatives at least). So it makes sense for a
PDF renderer to supply these fonts metrics to a formatter to say
hey, I can render these.

 Are you suggesting that FOP / FOray needs to actually query the hardware
 device and extract metrics information directly from it? Or is the plan 
I
 have outlined above sufficient?

Well, it really depends how far you want to go. Device fonts have 
certainly
seen days of higher importance... But still, from time to time you stumble
upon people who need (or want) to use fonts that they have no exact 
software
equivalent for. Whether this means accessing the device directly or 
indirectly
using a printer driver or by means of supplying metric files is a side 
issue,
I think. Let's just say a renderer should be able to supply fonts 
(metric-only
or complete) to the formatter.

To give you an extreme example: In the high-volume output market, the 
format
of choice is still AFP by IBM. This is (but today's standards) a rather
obscure format that has ancient origins in the GKS system and is very
similar to the metafile format in OS/2. Concerning fonts, however, you
mostly use bitmap fonts in the AFP world. Imagine a renderer that
has to support an output format that only allows (and supplies) bitmap 
fonts.

Sure, it's debatable whether one want to support this kind of thing - at 
least
by design. But, in any case, I think it highlights the extremes that can
happen in the font handling world.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

RE: Fonts

[Victor Mote]

Arnd Beißner wrote:

  So my *plan* has been that these fonts get treated pretty much like 
  any other font. The only thing about the hardware font is that it 
  can't be embedded -- it is already embedded all of the 
 places that it can be.
 
 Depends. Every PDF compliant reader/printer has to support 
 Adobe's standard Helvetica, Times Roman, Courier, Symbol and 
 Zapf Dingbats fonts (metrics-compatible alternatives at 
 least). So it makes sense for a PDF renderer to supply these 
 fonts metrics to a formatter to say hey, I can render these.

However, since these same fonts could also be used by the PostScript
renderer, or the Print or AWT renderers (assuming that the pfb is available
as well), I don't see a need to duplicate their definitions, or metrics, or
anything for each one of these environments, which is what it sounds like
you might be suggesting. It should be sufficient for the Renderer (or
RenderContext) to tell what it is *capable* of doing, without having to
provide the actual detail. In the case of the Base-14 font metrics, we can
and should and do embed them within FOP itself.

If you don't mind the metrics themselves living somewhere else, and the PDF
Renderer simply saying I can render Base-14 fonts, then we are in
agreement.

  Are you suggesting that FOP / FOray needs to actually query the 
  hardware device and extract metrics information directly 
 from it? Or 
  is the plan
 I
  have outlined above sufficient?
 
 Well, it really depends how far you want to go. Device fonts 
 have certainly seen days of higher importance... But still, 
 from time to time you stumble upon people who need (or want) 
 to use fonts that they have no exact software equivalent for. 
 Whether this means accessing the device directly or 
 indirectly using a printer driver or by means of supplying 
 metric files is a side issue, I think. Let's just say a 
 renderer should be able to supply fonts (metric-only or 
 complete) to the formatter.

Why is this better than simply supplying the same font metrics at a global
level, and letting the Renderer or RenderContext tell what it is/is not
capable of processing? What would one get in return for giving up that
simplicity?

 To give you an extreme example: In the high-volume output 
 market, the format of choice is still AFP by IBM. This is 
 (but today's standards) a rather obscure format that has 
 ancient origins in the GKS system and is very similar to the 
 metafile format in OS/2. Concerning fonts, however, you 
 mostly use bitmap fonts in the AFP world. Imagine a renderer 
 that has to support an output format that only allows (and 
 supplies) bitmap fonts.
 
 Sure, it's debatable whether one want to support this kind of 
 thing - at least by design. But, in any case, I think it 
 highlights the extremes that can happen in the font handling world.

After you have a generic font definition scheme, like an AFM parser or FOP's
metrics files, I think you can support any font, bitmap or otherwise. If the
hardware vendors can't provide the metrics, then someone would have to sit
down and either query the device or infer the metrics from output, or some
other method to get it into the standard form expected. It might be
worthwhile to add something in the font configuration that would identify
the point size, so that at least a warning could be generated if someone
tried to use, say, an 11-pt file at 9 points.

Victor Mote

Re: Fonts

[Peter B. West]

Victor Mote wrote:
Peter B. West wrote:
...

What I'm exploring is the possibility of going in the 
opposite direction.  That is, using the Interfaces and 
Classes of java text layout as a model for FOP layout, even 
if the implementation is FOP specific.  That way, when the 
Java model *is* adequate for FOP's use, it is a trivial 
matter.  The 2D model of text layout seems very powerful.

This is only opposite in the sense of how the abstraction works. Your
approach is pretty sound, and, assuming that you can solve the embedding
problem, has some merit. However, there is no reason that the isolated Font
logic can't use the awt objects that you are interested in to do the work
behind the interface that FOray is building (or something similar). By
isolating all of this code, you can have your cake and eat it too. You can
use awt if, when, and how much it really makes sense, and you can do all
kinds of other stuff as well for places where awt is inadequate. For
example, awt gives access to the OpenType tables, but really doesn't do
anything with them. FOray wants to use that information, and I assume that
FOP will eventually want to also. So, why limit yourself to awt? As I said
before, even if awt were perfect, there is still value in hiding it,
especially during a refactoring stage.
I am interested in the 2D approach for a couple of reasons.  Firstly, 
because I want a testbed for alt-design layout sooner rather than later. 
 Secondly, I was looking for a approach to fonts and layout that was 
not PDF-centric and that might be familiar to new folks coming in, so 
the idea of modelling it on 2D appealed.  Clearly, there is nothing of 
overwhelming relevance to HEAD in either approach.

...
Yes, and the renderer gets that information from the Font, which is still
the same Font, and has no idea who is using it or why or how.
I don't deny that the concept I have described as RenderContext (you may
have been off-line when we discussed this about a year ago) may affect
layout. Those differences must be considered during layout (but the logic of
handling them should not be done by the layout classes). RenderContext
describes the capabilities that are available, presumably what fonts are
available in this context, but could also include other things (can't kern,
can't do letter-spacing, can't stretch text, etc). AFAICT, PDF and
PostScript use the same RenderContext, but if there are differences, then
they can each have their own. Once these capabilities are defined, they must
be considered as the FOTree is built, and as layout is performed.
So, while the Font is always a constant, it needs to be filtered through
the lens of the RenderContext before it can be used properly. That is
probably why the Font stuff ended up in the Render classes. And that is
(part of) why I think, as FOP grows up here, it is important to distinguish
between the Renderer and the RenderContext.
java.awt.font.FontRenderContext performs this function for 2D font 
rendering.  The arguments to the constructor are the AffineTransform for 
scaling typographical points to renderer pixels, and the booleans 
isAntiAliased and usesFractionalMetrics.

If you'll give me a few weeks, I hope to be able to show you what I seem
unable to sell with words.
It will be good to see what you come up with.
Peter
--
Peter B. West http://www.powerup.com.au/~pbwest/resume.html

Re: Fonts

[Glen Mazza]

(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

Re: Fonts

[Peter B. West]

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

[Victor Mote]

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

Re: Fonts and Document

[Jeremias Maerki]

(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 

Re: Fonts and Document

[Simon Pepping]

On Wed, Mar 17, 2004 at 09:21:03AM +0800, Manuel Mall wrote:
 Simon,
 
 tried the URL you gave
 (http://www.leverkruid.nl/FOP/documentation.xml) and got the error (IE
 6):
 
 The system cannot locate the object specified. Error processing
 resource 'http://www.leverkruid.nl/FOP/docbookx.dtd'. 

The XML file is not meant to be viewed in the browser. If you try to
do that, the browser searches for the DTD because the document lists
one in its DOCTYPE declaration. And that DTD is not provided by my web
page. If you would have the DTD that would not help you because there
is no stylesheet associated with the XML file. The docbook stylesheets
are too large and complicated to be applied by a browser. You can only
save the XML file and apply XSL stylesheets to obtain an xhtml or pdf
file.
 
 Mozilla Firefox fails as well.

Same reason.
 
Regards, Simon Pepping

-- 
Simon Pepping
home page: http://www.leverkruid.nl

Re: Fonts and Document

[Simon Pepping]

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

[Manuel Mall]

Simon,

tried the URL you gave
(http://www.leverkruid.nl/FOP/documentation.xml) and got the error (IE
6):

The system cannot locate the object specified. Error processing
resource 'http://www.leverkruid.nl/FOP/docbookx.dtd'. 

Mozilla Firefox fails as well.

Manuel

Re: Fonts and Document

[Peter B. West]

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

[Simon Pepping]

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

Re: Fonts and Document

[Clay Leeds]

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

[Jeremias Maerki]

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

[J.Pietschmann]

Victor Mote wrote:
 OK, here is a related question that does not appear to be an FAQ (per my
 review of FOP, Batik, and Cocoon lists). If I try:
 ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
 
 in a headless environment, I get a runtime error that halts the JVM.

This is interesting, but you'll probably get more and better
answers on comp.lang.java or a more specialized Java forum.

 There
 does not seem to be a way to catch the error and skip the offending code
 (which is all I really need to do). It looks like 1.4 will throw a
 HeadlessException, and also gives a GraphicsEnvironment.isHeadless() method,
 both of which are helpful. However, in 1.3, I don't see a clean way to
 detect this -- I could probably do something klunky like looking at the
 $TERM variable  trying to figure it out from there.

I'd go for the DISPLAY environment variable: if it's not set, you
are most probably running headless. There is a slight possibility
you are on a system which would connect to a local X server anyway,
so just to be really, really sure open a socket to localhost:6000, and
perhaps emulate XOpenDisplay if there is something listening there.

I'm not sure why you take this trouble, can't you control or at least
reliably determine the run time environment in advance? You can
install PJA in case you encounter a headless Java 1.3 environment.

 On a related note, what are our criteria
 for determining support of various Java platforms?

There is a rule of thumb to support older environments up to two
years after the next major upgrade was available, perhaps with
slight restrictions. It depends on how much inconvenience this brings
to users of more recent versions, and on how much users of older
versions complain. There are people stuck with MS Java or IMB's
1.1.8 JRE on OS/390 USS, but they never showed up in person when it
came to discussions about dropping Java 1.1 support.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Rhett Aultman]

Responses below.

-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 3:05 PM
To: [EMAIL PROTECTED]
Subject: Re: fonts


Victor Mote wrote:
 OK, here is a related question that does not appear to be an FAQ (per my
 review of FOP, Batik, and Cocoon lists). If I try:
 ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
 
 in a headless environment, I get a runtime error that halts the JVM.

This is interesting, but you'll probably get more and better
answers on comp.lang.java or a more specialized Java forum.

I'm curious.  What's the error and stacktrace for that error?  Have you tried catching 
things of type Throwable?

 There
 does not seem to be a way to catch the error and skip the offending code
 (which is all I really need to do). It looks like 1.4 will throw a
 HeadlessException, and also gives a GraphicsEnvironment.isHeadless() method,
 both of which are helpful. However, in 1.3, I don't see a clean way to
 detect this -- I could probably do something klunky like looking at the
 $TERM variable  trying to figure it out from there.

I'd go for the DISPLAY environment variable: if it's not set, you
are most probably running headless. There is a slight possibility
you are on a system which would connect to a local X server anyway,
so just to be really, really sure open a socket to localhost:6000, and
perhaps emulate XOpenDisplay if there is something listening there.

Sun has looked on environment variables with derision, and the 1.3 JDK deprecates the 
mechanisms by which you can extract them in Java.  IIRC, the getenv mechanism was 
actually de-implmented in JDK 1.4.  You might face similar trouble in 1.3.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Victor Mote]

J.Pietschmann wrote:

  in a headless environment, I get a runtime error that halts the JVM.

 This is interesting, but you'll probably get more and better
 answers on comp.lang.java or a more specialized Java forum.

I wasn't looking for an answer here, as I really didn't think there was a
java solution. This was simply background for a discussion about how best to
work around it in the font work I am doing.

 I'm not sure why you take this trouble, can't you control or at least
 reliably determine the run time environment in advance? You can
 install PJA in case you encounter a headless Java 1.3 environment.

Perhaps I did not give enough background. One of the reasons for the font
refactoring work I am doing is to give FOP access to system fonts. These
fonts are available through methods in
java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(). The JDK will
compile the code, but the runtime was choking in a headless environment.
Since I am writing this as an enhancement for FOP in general (as opposed to
only my own installation), the answer is no -- I cannot control or determine
the runtime environment in advance.

Rhett Aultman wrote:

 I'm curious.  What's the error and stacktrace for that error?
 Have you tried catching things of type Throwable?

I had tried to catch a RunTimeException without success. It frankly did not
occur to me to try to catch a Throwable, but based on your suggestion, I
did, and it does catch it correctly. Thanks very much. Also, my apologies to
Joerg et al for asking a java question here -- I really did think it was a
FOP workaround question.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Victor Mote]

J.Pietschmann wrote:

 Victor Mote wrote:
  Is it safe to assume that all *n*x
  platforms have or could get an X environment?
 No. This is a FAQ. It seems to be quite common for servers to come
 without X libraries installed, search the FOP, Cocoon and Batik lists for
 headless server.

OK, here is a related question that does not appear to be an FAQ (per my
review of FOP, Batik, and Cocoon lists). If I try:
ge = GraphicsEnvironment.getLocalGraphicsEnvironment();

in a headless environment, I get a runtime error that halts the JVM. There
does not seem to be a way to catch the error and skip the offending code
(which is all I really need to do). It looks like 1.4 will throw a
HeadlessException, and also gives a GraphicsEnvironment.isHeadless() method,
both of which are helpful. However, in 1.3, I don't see a clean way to
detect this -- I could probably do something klunky like looking at the
$TERM variable  trying to figure it out from there. We could conceivably
use a configuration entry or environment variable to flag this (with
headless defaulting to yes -- in other words, they would have to
override it with no for us to know that they are in a graphical
environment). I don't mind doing that, but I don't want to create a bunch of
support headaches. Any suggestions? On a related note, what are our criteria
for determining support of various Java platforms? In other words, at what
point would we insist on 1.4 as the minimum platform supported by FOP? I'm
not suggesting that we should do that, but just thinking through the costs 
benefits of an interim solution.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Victor Mote]

Jeremias Maerki wrote:

 I'm talking mainly about font metrics at the moment. There are several
 areas to the whole discussion though:
 - font metrics (has an effect on the layout/appearance)
 - available fonts (different font types and sources, different quality
   of information)
 - font embedding (how do I get to the physical font and how do I
   transform it for the target format)
 - character encodings
 - speed and memory consumption issues
 (forgot anything?)

That list looks complete to me.

 Right. What would that class you propose be? I don't think you have to
 change a lot, just do a refactoring step to streamline the whole stuff.
 If you like my font manager approach (which handles the different font
 sources), maybe that's your class to build. It would be rather cool if
 the font stuff could be moved from the layout and render packages over
 to the font package so it is pretty isolated. Also makes it easier to
 work on and to provide a clean solution.

I agree with all of that. I intend to leave existing logic alone as much as
possible, but to put a layer on top of it, then add the AWT stuff on under
that layer (ie. as a sister layer to the existing stuff). I'll probably
leave the moving to different packages to someone with commit access, as I
don't see how to roll that up into a submittable patch. However, I agree
that we should isolate and generalize it as much as possible. Also, I will
build any new classes in the fonts package.

 One last question: you're planning to work on the redesign branch, right?

Actually, I was planning on working in the maint branch for a whole bunch of
reasons. If you think it is important to work in the trunk, I'll reconsider.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Jeremias Maerki]

Good discussion you two had. Jörg injected about the same things I would
have.

In the back of my mind I have a reminder that AWT has some strange
behaviour in font handling making it difficult to produce high-quality
text. Looking at org.apache.fop.render.awt.AWTFontMetrics there is a
pointer to an AWT bug. There's other code in there that hints at
deficiencies in AWT. And there are differences between JDK versions!
Here are some thoughts:
- I think it would be good if we could provide fonts for the PDF and
  other renderers from the AWT, because it would make it easier for
  users to add new fonts and it is consistent with Batik's approach...
- ...but will we be able to get at the physical font in order to embedd
  it in the target file? While quickly looking into the AWT API I
  haven't found anything approriate. And where will we configure that a
  particular font should be embedded?
- Will we have enough information out of AWT to produce high-quality
  text? For example, you need accurate information for the placement of
  under/overlines and superscript stuff.

So having said that and considering what has been said before I think
relying on AWT for font handling cannot be the only answer. I'm still on
the same track as before wanting a font manager for FOP that can handle
multiple font sources. This means a good heap of work but will give us
the necessary flexibility to cope with almost every situation. That
doesn't mean we have to provide everything immediately. Incremental
improvement will do just fine.

Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Ralph LaChance]

At 02:31 AM 10/8/02, you wrote:
Will we have enough information out of AWT to produce high-quality
   text? For example, you need accurate information for the placement of
   under/overlines and superscript stuff.


$.02:

Underlines are in the (newish) LineMetrics object available from a Font,
nothing I know of about overlines, sub/super script per se.

One piece of bad news is that presently the JDK has a problem producing
identical output to the screen vs a printer (I documented the problem here a
couple months ago viz-a-viz Windows, at least.)  As I recall, the rasterizer
comes up with output glyphs that do not match the size predicted by
measuring text using the font-metrics.

Even worse is that it seems to fails differently between depending on major
version ~ 1.3 and 1.4 ~ (maybe even among sub versions.)

I recall wondering if fop could get better results in the awt if, at the 
time it
creates its reference font metrics, it were to know the actual target
(ie printer vs screen vs pdf) graphics context.  Then I wondered what this
had to do with pdf and went to sleep...



 ' Best,
 -Ralph LaChance



 In theory, there is no difference between
 theory and practice, but in practice there is.

 (Someone wrote that, but I don't know who.)




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Victor Mote]

Jeremias Maerki wrote:

 In the back of my mind I have a reminder that AWT has some strange
 behaviour in font handling making it difficult to produce high-quality
 text. Looking at org.apache.fop.render.awt.AWTFontMetrics there is a
 pointer to an AWT bug. There's other code in there that hints at
 deficiencies in AWT. And there are differences between JDK versions!

Acknowledged. Being quite a bit of an incrementalist myself, the scope of
the project that I am contemplating revolved around only the FontMetrics --
in other words, it would only replace the font metric information that we
currently get from the generated XML files. Layout and rendering chores
could be added later, iff they made sense. Are the problems you are seeing
related to the metrics or to other issues? Obviously if the basic metrics we
get out of AWT are bad, that would be a deal killer.

In addition to the JDK version, there is a JRE issue here as well that I
neglected to mention. Since the createFont method doesn't exist until 1.3,
wouldn't that be the minimum JRE that could be used to run FOP if we rely on
that to get unregistered font information?

 - ...but will we be able to get at the physical font in order to embedd
   it in the target file? While quickly looking into the AWT API I
   haven't found anything approriate. And where will we configure that a
   particular font should be embedded?

This is a good point. I don't see where java tells us how to get to the
physical file either. However, we have to configure a path to the physical
file now to embed the font, so we aren't really going backwards on this
issue. Also, I see no problem with using the current scheme for configuring
the embedding (i.e. if embed-file exists, use it, otherwise, don't embed).
The trick will be, if we use the AWT, to teach the users how to make sure
that the names match or map properly. We may need to build a qd tool to let
the users see the fonts (and names) on their system that AWT can see.

 - Will we have enough information out of AWT to produce high-quality
   text? For example, you need accurate information for the placement of
   under/overlines and superscript stuff.

If we are talking about metric info only, I think so, but I could be wrong.

 So having said that and considering what has been said before I think
 relying on AWT for font handling cannot be the only answer. I'm still on
 the same track as before wanting a font manager for FOP that can handle
 multiple font sources. This means a good heap of work but will give us
 the necessary flexibility to cope with almost every situation. That
 doesn't mean we have to provide everything immediately. Incremental
 improvement will do just fine.

You have convinced me. Here is what I propose: Hide both the current design
and the AWT fonts behind a class that is used everywhere within FOP. If the
AWT approach is flaky for any reason, we can always fall back on the current
approach, but we can then experiment at will with AWT (at the metrics
level). To make this work, we'll need to look in the configuration info for
fonts before looking at AWT. This also means we don't need to do anything
with createFont for the moment, which also makes the JRE issue go away. The
downside is that we won't be able to mess with AWT for layout help (unless a
similar approach is taken to hide the differences there).

I think that will keep me busy for a couple of minutes :-) Thanks again for
all of the good insight.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Jeremias Maerki]

  In the back of my mind I have a reminder that AWT has some strange
  behaviour in font handling making it difficult to produce high-quality
  text. Looking at org.apache.fop.render.awt.AWTFontMetrics there is a
  pointer to an AWT bug. There's other code in there that hints at
  deficiencies in AWT. And there are differences between JDK versions!
 
 Acknowledged. Being quite a bit of an incrementalist myself, the scope of
 the project that I am contemplating revolved around only the FontMetrics --
 in other words, it would only replace the font metric information that we
 currently get from the generated XML files. Layout and rendering chores
 could be added later, iff they made sense. Are the problems you are seeing
 related to the metrics or to other issues? Obviously if the basic metrics we
 get out of AWT are bad, that would be a deal killer.

I'm not a guru on this but the AWT font metrics are not that bad just
not fully complete. Using our own FontMetrics abstraction means that we
can adapt to other metric sources. That's what is in place and what I
think can be built upon. So yes, the problems I see are related to font
metrics.

 In addition to the JDK version, there is a JRE issue here as well that I
 neglected to mention. Since the createFont method doesn't exist until 1.3,
 wouldn't that be the minimum JRE that could be used to run FOP if we rely on
 that to get unregistered font information?

I think so.

This is another reason not to rely too heavily on AWT. Once we have the
possibility to supply JDK-dependent code it will make it easier to
provide the best functionality possible.

  - ...but will we be able to get at the physical font in order to embedd
it in the target file? While quickly looking into the AWT API I
haven't found anything approriate. And where will we configure that a
particular font should be embedded?
 
 This is a good point. I don't see where java tells us how to get to the
 physical file either. However, we have to configure a path to the physical
 file now to embed the font, so we aren't really going backwards on this
 issue. Also, I see no problem with using the current scheme for configuring
 the embedding (i.e. if embed-file exists, use it, otherwise, don't embed).
 The trick will be, if we use the AWT, to teach the users how to make sure
 that the names match or map properly. We may need to build a qd tool to let
 the users see the fonts (and names) on their system that AWT can see.

I agree. Maybe we can simplify the embedding business by just having a
section in the configuration where you can supply a list of font names
that should be embedded. That provides an opportunity to break away from
having to register each single font though that should still be possible. I'd
like to go as far as providing an extension so you could specify in the
FO file that some particular font should be embedded (but that's for
later).

  - Will we have enough information out of AWT to produce high-quality
text? For example, you need accurate information for the placement of
under/overlines and superscript stuff.
 
 If we are talking about metric info only, I think so, but I could be wrong.

I hope so. :-) The AWT renderer already relies on this but I know there
are noticable differencies between PDF and AWT output. The issue of
producing the same output with different renderers has come up several
times already.

I'm talking mainly about font metrics at the moment. There are several
areas to the whole discussion though:
- font metrics (has an effect on the layout/appearance)
- available fonts (different font types and sources, different quality
  of information)
- font embedding (how do I get to the physical font and how do I
  transform it for the target format)
- character encodings
- speed and memory consumption issues
(forgot anything?)

  So having said that and considering what has been said before I think
  relying on AWT for font handling cannot be the only answer. I'm still on
  the same track as before wanting a font manager for FOP that can handle
  multiple font sources. This means a good heap of work but will give us
  the necessary flexibility to cope with almost every situation. That
  doesn't mean we have to provide everything immediately. Incremental
  improvement will do just fine.
 
 You have convinced me. Here is what I propose: Hide both the current design
 and the AWT fonts behind a class that is used everywhere within FOP. If the
 AWT approach is flaky for any reason, we can always fall back on the current
 approach, but we can then experiment at will with AWT (at the metrics
 level). To make this work, we'll need to look in the configuration info for
 fonts before looking at AWT. This also means we don't need to do anything
 with createFont for the moment, which also makes the JRE issue go away. The
 downside is that we won't be able to mess with AWT for layout help (unless a
 similar approach is taken to hide the differences there).

RE: fonts

[Victor Mote]

J.Pietschmann wrote:

 Well, as far as I understand TTF and PFB files have a directory
 and lots of pointers to other parts of the file. The metric
 extractor loads the whole file into memory, for convenience.
 This can be a significant memory load, and all the glyph
 geometry definitions take up space unnecessarily.
 This could probably be avoided using the RandomAccessFile class,
 but I expect performance going down the toilet in this case.

If I followed this, then we would expect the current method to use a more
memory, but less processor time, while parsing the font file at runtime
would likely use less memory, but more processing. Am I understanding you
correctly? (I understand that we are speaking in terms of expectations, not
having actually measured the effects of either approach). The other question
that I should bring in here is whether any one has real-world experience
with the tradeoffs of using  java.awt.Font. And more importantly, are any of
these tradeoffs in any of these three scenarios worth considering. In other
words, should be worry about these issues at all, or assume that Moore's Law
will in good time fix all of them? This is not a rhetorical question.

 Another point, important IMO, is that the metrics file can be
 edited after extraction. Some fonts contain awful data.

I understand what you are saying, but I almost think this is a negative. If
the font metrics we use are incomplete because we aren't looking at the
other Type 1 pieces, that should be fixable. If they are bad because the
font is bad, I am not sure how much we want to encourage the use of bad
fonts. Pointers to font editing software and reliable font suppliers might
be more productive. The real question here is whether, if we had an
alternative that would allow us to abstract fonts at the java level instead
of at the FOP level, would we be willing to give up the ability to hack the
metrics files in exchange?

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Victor Mote]

J.Pietschmann wrote:

 Jeremias Maerki wrote:
  Don't ask me for details (because I wasn't directly involved) but we had
  to register new fonts with Linux so they got available in Batik for SVG.
  So there seems to be some kind of font registry in Linux.

 That's probably the X Windows font registry which is used by the
 AWT, whose fonts are in turn used by Batik.

That makes sense, and I'll investigate it further on my Linux box. I
hesitated to do so before because I assumed that the use of the font metrics
files was to overcome a limitation here, perhaps when running *n*x in
character mode.

Jeremias Maerki wrote (speaking of problems with font metrics in Type 1
fonts):

 The reason for that is that currently, only the PFM file of a font is
 used to generate the XML font metrics file. The PFM lacks certain values
 that subsequently have to be guessed. These guesses tend to be wrong
 relatively often. To fix this FOP would have to learn the ability to
 also parse the AFM and maybe values from the PFB. I think the TrueType

If java can see the font files, this work has already been done for us. I
guess I am trying to push the level of font abstraction up a notch or two
higher if possible.

  1. Replace current font-by-font configuration item with a path
 to the font
  file itself. When the font is used in a session, parse the metric
  information in real time from the font file.
 
  2. Add a configuration item that contains a PATH-like list of
 directories in
  which font files are located. When a font is requested in a
 session, search
  the path for the font file, parse it, and use it. (There would
 seem to be a
  performance penalty for this, so it should be optional).
 
  3. [This one is only half-baked]. Extend or otherwise hack the
  GraphicsEnvironment and/or java.awt.font classes to see non-registered
  fonts as if they were registered. In other words, to parse the
 fonts from
  the font files (found in the configuration file or PATH) and create
  java.awt.font objects for them that can be used. I do not know
 whether this
  is feasible, but if it were, it seems like we might gain a
 bunch of benefits
  from using the Java 2D classes that use these classes. If this is an
  impossible or otherwise bad idea, perhaps it will trigger a good one in
  someone else.

 Yes please!!! But don't forget to provide backwards compatibility
 (loading a font from a XML font metric file). Depending on what's faster
 it may be beneficial to generate an XML font metric file into some
 configurable directory acting as some kind of persistant font cache, the
 first time the font is loaded. Adobe Acrobat Reader does something
 similar, too.

My three proposals were predicated on the assumption that there was some
cross-platform need for the generated font metrics information. If in fact
we can find a way to register the fonts at the O/S level and let java see
them that way, would that not be better than any of the three options above?
The following objections come to mind:
1. Refactoring work. Answer: True, but all of the other options generate
work as well, including the status quo (which generates work for the user,
and support questions for us).
2. We exchange support of font metric generation for support of getting
fonts registered at the O/S level. Answer: True, but it would seem that
these would pretty much offset.
3. This might reduce FOP functionality on some platforms (ie. if unable to
register the fonts, can't use them anymore). Answer: True, and this is the
one that concerns me the most. However, they won't be able to run Batik
either (if I understand correctly). Is it safe to assume that all *n*x
platforms have or could get an X environment?

Unless java.awt.GraphicsEnvironment can be tricked into seeing unregistered
fonts, the current design and using java.awt.Font seem mutually exclusive.
It would be very helpful to hear comments about objection 3 above (potential
reduced functionality on some platforms).

Thanks to both Jeremias  Joerg for their help. I think I have enough to
keep me busy for a while.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[J.Pietschmann]

Victor Mote wrote:
 If I followed this, then we would expect the current method to use a more
 memory, but less processor time, while parsing the font file at runtime
 would likely use less memory, but more processing.

I meant: If you are going to extract the font metrics from the
original font file directly, you have basically two alternatives:
- load the whole file into an array in order to get fast random
   access
- make frequent seeks and read lots of small data packets (often
   a few bytes) in order to minimize memory load
Either possibility is prospective for western fonts, which are
generally small, and not all that much different characters are
used. The first possiblity can be ruled out for large Unicode
fonts, even if you only use a few characters. Far eastern users
will probably have problems with both solutions.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[J.Pietschmann]

Victor Mote wrote:
 Is it safe to assume that all *n*x
 platforms have or could get an X environment?
No. This is a FAQ. It seems to be quite common for servers to come
without X libraries installed, search the FOP, Cocoon and Batik lists for
headless server. Also, there are providers out there who run Cocoon or
a general servlet environment but make it difficult to install it as
headless, and some even refuse to install the X libraries for
security reasons or whatever.

I personally had to go to some length to have my application server at
work installed with PJA, even though a X server is running. The X
security settings prevent the application server from accessing the X
server, and the server staff just refused to change anything (I suspect
they don't have a clue how to fiddle with the X security stuff).

Well, FOP is already so tightly integrated with Batik that it wont run
without X or PJA. However, I suspect that talking an ISP/ASP into installing
additional fonts will be more often a major PITA than not, and this
could easily be seen as significant drawback of the use the system fonts
approach. And if I were a server provider, I'd be uneasy with customers
dragging in heaps of fonts I have to install and manage. Apart from the
potential to have clashes, getting the X font subsystem to perform with
lots of fonts apparently requires some rather arcane knowledge.
The problem with PJA OTOH is that it is sloow , and it only accepts one
font file format (TTF IIRC, it is OSS though, someone out there to fix it?)

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Victor Mote]

J.Pietschmann wrote:

 Victor Mote wrote:
  Is it safe to assume that all *n*x
  platforms have or could get an X environment?
 No. This is a FAQ.

Sorry. I have seen headless server postings go by, but it meant nothing to
me.

 Well, FOP is already so tightly integrated with Batik that it wont run
 without X or PJA. However, I suspect that talking an ISP/ASP into
 installing
 additional fonts will be more often a major PITA than not, and this
 could easily be seen as significant drawback of the use the system fonts
 approach. And if I were a server provider, I'd be uneasy with customers
 dragging in heaps of fonts I have to install and manage. Apart from the
 potential to have clashes, getting the X font subsystem to perform with
 lots of fonts apparently requires some rather arcane knowledge.

Good point, and one that I would not have thought of working in a standalone
 static environment. The question then becomes whether 1) FOP should
dictate to the end-user that it can only use registered fonts, or 2) the
end-user's environment limitations should dictate to FOP that it must build
yet another independent font registry system. I am OK with either one, but I
think it is good to ask the question before proceeding, as the ripple effect
of this decision seems significant. If 99% of ISP/ASP users are using only
fonts that would be on their server, or if we don't mind telling them that
they should (or use an in-house server, or get the ISP to install the fonts,
or ...), then maybe we come to a different decision. How do the other
implementations handle this issue? I definitely don't intend to be
argumentative here. I may be the odd man out, as the axis that we are
concerned with has less to do with servers  performance than typographical
flexibility.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Victor Mote]

Victor Mote wrote:

 of this decision seems significant. If 99% of ISP/ASP users are using only
 fonts that would be on their server, or if we don't mind telling them that
 they should (or use an in-house server, or get the ISP to install
 the fonts,
 or ...), then maybe we come to a different decision. How do the other

I just found something in the Java 1.3 javadocs that wasn't in my JFC book
(which must cover 1.2): a createFont method in java.awt.Font, which will
create a Font instance from an InputStream. It appears to only handle
TrueType right now. However, Type 1 fonts can be converted to TrueType.
Since OpenType isn't supported right now, I don't think anyone can complain
that it wouldn't be supported under this scheme. Unless someone thinks the
Type 1 to TrueType conversion is too big of an issue, or has some other
objection, I'll work on this approach. My apologies for using up so much
bandwidth.

Victor Mote


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Peter B. West]

Victor Mote wrote:
  My apologies for using up so much
 bandwidth.

Victor,

That's what it's there for.  No apology required.

Peter
-- 
Peter B. West  [EMAIL PROTECTED]  http://www.powerup.com.au/~pbwest/
Lord, to whom shall we go?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[J.Pietschmann]

Victor Mote wrote:
 I am thinking through ways to eliminate as much user involvement in using
 non-base-14 fonts as possible. Is there a performance benefit to parsing the
 XML metric files instead of extracting the information directly from the
 font file itself at runtime?

Well, as far as I understand TTF and PFB files have a directory
and lots of pointers to other parts of the file. The metric
extractor loads the whole file into memory, for convenience.
This can be a significant memory load, and all the glyph
geometry definitions take up space unnecessarily.
This could probably be avoided using the RandomAccessFile class,
but I expect performance going down the toilet in this case.
Another point, important IMO, is that the metrics file can be
edited after extraction. Some fonts contain awful data.

I agree that user fonts should be made more usable, for example
by integrating a one step font metrics generation and installation
into the main command line application. Another possibility would
be a metrics file repository, combined with a tool which searches
the repository and the locally installed fonts and then installs
the font in the FOP config.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Jeremias Maerki]

Hi Victor

On 05.10.2002 22:51:28 Victor Mote wrote:
 Jeremias  other FOP Developers:
 
 In addition to OpenType support, the other goal that I had for font work is
 to support arbitrary fonts. My initial thoughts in this area revolved around
 using the Java 2D capabilities. I understood that the GraphicsEnvironment
 can only see what the O/S shows it, but it did not immediately dawn on me
 that the more popular O/Ss for running FOP are probably Linux  Unix may not
 have a concept of font registration like Windows  Mac do. (If there is a
 way to register fonts in the character environments of these platforms in
 such a manner that java can see them, please let me know -- I have looked
 for this, but have not found it.)

Don't ask me for details (because I wasn't directly involved) but we had
to register new fonts with Linux so they got available in Batik for SVG.
So there seems to be some kind of font registry in Linux. Don't know
about the other unixes but I guess they will be the same.

 Question: Is it therefore fair to conclude that the reason for using the
 generated XML metric files is to provide a platform-neutral way of getting
 such information, especially for non-graphical environments? The following
 discussion assumes that the answer to this question is yes.

Not really. I think it's more of a historical thing. In the beginning
there was a class for each of the base 14 fonts (still in use today).
These classes are generated from XML files in the codegen directory.
Then, when I started to get involved, I finished work by others so we
could programmatically register Java classes generated from XML font
metric files (almost the same as today) in FOP. Tore Engvig then took
over, implemented TrueType support and provided a way for FOP to load
the XML font metric files directly. That's how things are today.

 I am thinking through ways to eliminate as much user involvement in using
 non-base-14 fonts as possible. Is there a performance benefit to parsing the
 XML metric files instead of extracting the information directly from the
 font file itself at runtime? If so, then perhaps I should just leave this
 alone. If not, then I see some options for possible improvement, listed from
 least radical to most.

I don't know what would be faster. We'd have to do some performance
measurings. As Joerg said, there's a benefit of being able to edit the
XML font metrics. You may have read the recent problem Paul Thibodeaux
reported with a PS Type 1 font. I've had this kind of problems before.
The reason for that is that currently, only the PFM file of a font is
used to generate the XML font metrics file. The PFM lacks certain values
that subsequently have to be guessed. These guesses tend to be wrong
relatively often. To fix this FOP would have to learn the ability to
also parse the AFM and maybe values from the PFB. I think the TrueType
support may have similar problem but far less often. I'm not sure
because I don't work with TrueType fonts.

 1. Replace current font-by-font configuration item with a path to the font
 file itself. When the font is used in a session, parse the metric
 information in real time from the font file.

 2. Add a configuration item that contains a PATH-like list of directories in
 which font files are located. When a font is requested in a session, search
 the path for the font file, parse it, and use it. (There would seem to be a
 performance penalty for this, so it should be optional).
 
 3. [This one is only half-baked]. Extend or otherwise hack the
 GraphicsEnvironment and/or java.awt.font classes to see non-registered
 fonts as if they were registered. In other words, to parse the fonts from
 the font files (found in the configuration file or PATH) and create
 java.awt.font objects for them that can be used. I do not know whether this
 is feasible, but if it were, it seems like we might gain a bunch of benefits
 from using the Java 2D classes that use these classes. If this is an
 impossible or otherwise bad idea, perhaps it will trigger a good one in
 someone else.

Yes please!!! But don't forget to provide backwards compatibility
(loading a font from a XML font metric file). Depending on what's faster
it may be beneficial to generate an XML font metric file into some
configurable directory acting as some kind of persistant font cache, the
first time the font is loaded. Adobe Acrobat Reader does something
similar, too.

For Type 1 font support that would mean that we have to write a AFM
and/or PFB parser (already on my todo list, but I'm lacking time ATM) so
we get better reliability for these fonts.

 I am betting that some of you have thought about these issues for a while,
 so I ask the questions hoping that you can save me many hours of tedious
 unfruitful work.

Today, making fonts available is the responsibility of the renderer. I'm
not sure if this is good. I'd prefer a central font manager which can
provide fonts from various sources (AWT, directories containing TTFs 

Re: fonts

[J.Pietschmann]

Jeremias Maerki wrote:
 Don't ask me for details (because I wasn't directly involved) but we had
 to register new fonts with Linux so they got available in Batik for SVG.
 So there seems to be some kind of font registry in Linux.

That's probably the X Windows font registry which is used by the
AWT, whose fonts are in turn used by Batik.

J.Pietschmann


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Jochen . Maes]

did you set the basedir? that migh give problems...
try to uncheck it if you set it...

Jochen



Jochen Maes
EDP departement
Programmeur

KBC-Securities
Havenlaan 16
1080 Brussel

Tel : 02/429.96.81
Fax : 02/429.17.48
E-mail : [EMAIL PROTECTED]

**

This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. You must not,
directly or indirectly, use, disclose, distribute, print, or copy any part
of this message if you are not the intended recipient. KBC Securities
reserves the right to monitor all e-mail communications through its
networks. Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is
authorised to state them to be the views of any such entity.
**


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Raúl Carazo]

At the end, I use the fonts, but only if I set them on the weblogic dir. Is
it necessary, or I can set in in the server dir?

I hope this is the last question...!

Thx


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Buchtík, Michal]

Ok, I use this and it works.

I use Tomcat 4.0.1, JDK 1.3.1, Fop 0.20.2

Do you try to use it from command line? It works?
And when you run servlet it don't works? In this case, I think, there is an
error in servlet when you specify the userconfig.xml file.

Good luck :-)

--- xsl file
xsl:template name=caption
fo:block font-size=18pt line-height=20pt font-family=Verdana
space-after.optimum=1pt color=black border-bottom=solid
2pt black
text-align=start padding-top=0pt font-weight=bold
xsl:value-of select=caption/
/fo:block
/xsl:template

 result 
fo:block font-size=18pt line-height=20pt font-family=Verdana
space-after.optimum=1pt color=black border-bottom=solid 2pt black
text-align=start padding-top=0pt font-weight=bold
 SOME TEXT IN VERDANA FONT HERE
/fo:block

-- this is from userconfig.xml
fonts
!-- VERDANA --
 font metrics-file=c:\xmllib\fonts\verdana.ttf.xml kerning=yes
embed-file=c:\xmllib\fonts\verdana.ttf
font-triplet name=Verdana style=normal weight=normal/
 /font
 font metrics-file=c:\xmllib\fonts\verdanab.ttf.xml kerning=yes
embed-file=c:\xmllib\fonts\verdanab.ttf
font-triplet name=Verdana style=normal weight=bold/
 /font
 font metrics-file=c:\xmllib\fonts\verdanai.ttf.xml kerning=yes
embed-file=c:\xmllib\fonts\verdanai.ttf
font-triplet name=Verdana style=italic weight=normal/
 /font
 font metrics-file=c:\xmllib\fonts\verdanaz.ttf.xml kerning=yes
embed-file=c:\xmllib\fonts\verdanaz.ttf
font-triplet name=Verdana style=italic weight=bold/
 /font
/fonts


-Original Message-
From: Raúl Carazo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 27, 2001 6:24 PM
To: [EMAIL PROTECTED]
Subject: RE: Fonts


Thanks to all of you, really!!

But I'm not using the example. In fact, if I try to use it, everything
works, but when I move it to my servlet...
It's really strange, because if I set any font, it appears with Times New
Roman (the default one), but if I don't set it, it appears with Arial!!!

Anyway, thank you!

Salve

P.S. I send you the right xsl:

xsl:attribute-set name=style
  xsl:attribute name=font-size10pt/xsl:attribute
/xsl:attribute-set

With this style, the font is Arial

If I set this one:

xsl:attribute-set name=style
  xsl:attribute name=font-size10pt/xsl:attribute
  xsl:attribute name=font-familyVerdana/xsl:attribute
  xsl:attribute name=font-style/
/xsl:attribute-set

(with Verdana or any other font), the font is Times New Roman.

And if I set:

xsl:attribute-set name=style
  xsl:attribute name=font-size10pt/xsl:attribute
  xsl:attribute name=font-familyVerdana/xsl:attribute
/xsl:attribute-set

there is an exception.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Buchtík, Michal]

You must run

Fop -c conf/userconfig.xml

in userconfig.xml you must define Verdana font

see http://xml.apache.org/fop/fonts.html

-Original Message-
From: Raúl Carazo [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 26, 2001 4:47 PM
To: FOP
Subject: Fonts


Hi everyone upthere

I'm trying to change the fonts in a pdf report. I have made the
xml-report and I have its xsl file for formatting it on this way:

?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fo=http://www.w3.org/1999/XSL/Format;
xsl:attribute-set name=styleParam
xsl:attribute name=font-size10pt/xsl:attribute
xsl:attribute name=font-familyVerdana/xsl:attribute
xsl:attribute name=font-style/
/xsl:attribute-set
/xsl:stylesheet
But I can't change the font (it appears as TimesNewRoman!!).

Where is my mistake (obviously, it HAS to be a mistake... I hope!)


Thx

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Raúl Carazo]

But I'm using it from a servlet. And I do call to the userconfig file. This
file contains a line like this:
font metrics-file=complete Path for the verdana.xml file kerning=yes
embed-file=
   font-triplet name=Verdana style=normal weight=normal/
  /font


- Original Message -
From: Buchtík, Michal [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 27, 2001 10:26 AM
Subject: RE: Fonts


You must run

Fop -c conf/userconfig.xml

in userconfig.xml you must define Verdana font

see http://xml.apache.org/fop/fonts.html

-Original Message-
From: Raúl Carazo [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 26, 2001 4:47 PM
To: FOP
Subject: Fonts


Hi everyone upthere

I'm trying to change the fonts in a pdf report. I have made the
xml-report and I have its xsl file for formatting it on this way:

?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fo=http://www.w3.org/1999/XSL/Format;
xsl:attribute-set name=styleParam
xsl:attribute name=font-size10pt/xsl:attribute
xsl:attribute name=font-familyVerdana/xsl:attribute
xsl:attribute name=font-style/
/xsl:attribute-set
/xsl:stylesheet
But I can't change the font (it appears as TimesNewRoman!!).

Where is my mistake (obviously, it HAS to be a mistake... I hope!)


Thx

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Buchtík, Michal]

font metrics-file=complete Path for the verdana.xml file kerning=yes
embed-file=HERE MUST BE COMPLETE PATH TO verdana.ttf

i use this

 font metrics-file=c:\fonts\verdana.ttf.xml kerning=yes
embed-file=c:\fonts\verdana.ttf
font-triplet name=Verdana style=normal weight=normal/
 /font


-Original Message-
From: Raúl Carazo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 27, 2001 10:22 AM
To: [EMAIL PROTECTED]
Subject: RE: Fonts


But I'm using it from a servlet. And I do call to the userconfig file. This
file contains a line like this:
font metrics-file=complete Path for the verdana.xml file kerning=yes
embed-file=
   font-triplet name=Verdana style=normal weight=normal/
  /font


- Original Message -
From: Buchtík, Michal [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 27, 2001 10:26 AM
Subject: RE: Fonts


You must run

Fop -c conf/userconfig.xml

in userconfig.xml you must define Verdana font

see http://xml.apache.org/fop/fonts.html

-Original Message-
From: Raúl Carazo [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 26, 2001 4:47 PM
To: FOP
Subject: Fonts


Hi everyone upthere

I'm trying to change the fonts in a pdf report. I have made the
xml-report and I have its xsl file for formatting it on this way:

?xml version=1.0?
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fo=http://www.w3.org/1999/XSL/Format;
xsl:attribute-set name=styleParam
xsl:attribute name=font-size10pt/xsl:attribute
xsl:attribute name=font-familyVerdana/xsl:attribute
xsl:attribute name=font-style/
/xsl:attribute-set
/xsl:stylesheet
But I can't change the font (it appears as TimesNewRoman!!).

Where is my mistake (obviously, it HAS to be a mistake... I hope!)


Thx

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Fonts

[Rajendran S]

Why Verdana is within Quotes in your xsl?


From: Raúl Carazo [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: FOP [EMAIL PROTECTED]
Subject: Fonts
Date: Wed, 26 Dec 2001 16:46:44 +0100
MIME-Version: 1.0
Received: from [64.125.133.20] by hotmail.com (3.2) with ESMTP id 
MHotMailBDF33AFA004C40043798407D85140F250; Wed, 26 Dec 2001 07:42:50 -0800
Received: (qmail 32150 invoked by uid 500); 26 Dec 2001 15:45:24 -
Received: (qmail 32137 invoked from network); 26 Dec 2001 15:45:21 -
From fop-dev-return-12286-srajendran Wed, 26 Dec 2001 07:42:52 -0800
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Precedence: bulk
list-help: mailto:[EMAIL PROTECTED]
list-unsubscribe: mailto:[EMAIL PROTECTED]
list-post: mailto:[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
Message-ID: 006601c18e24$87265e10$44010059@bm068
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Hi everyone upthere

 I'm trying to change the fonts in a pdf report. I have made the 
xml-report and I have its xsl file for formatting it on this way:

?xml version=1.0?

xsl:stylesheet version=1.0 
xmlns:xsl=http://www.w3.org/1999/XSL/Transform; 
xmlns:fo=http://www.w3.org/1999/XSL/Format;

xsl:attribute-set name=styleParam

xsl:attribute name=font-size10pt/xsl:attribute

xsl:attribute name=font-familyVerdana/xsl:attribute

xsl:attribute name=font-style/

/xsl:attribute-set

/xsl:stylesheet

But I can't change the font (it appears as TimesNewRoman!!).

 Where is my mistake (obviously, it HAS to be a mistake... I hope!)


 Thx




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Buchtík, Michal]

I update the FopServlet from examples dir.
like this

.
response.setContentType(application/pdf);

File userConfigFile = new File(C:/xmllib/conf/userconfig.xml);
Options options = new Options(userConfigFile);

Driver driver = new Driver(foFile, out);
driver.setLogger(log);
driver.setRenderer(Driver.RENDER_PDF);
driver.run();
...

this works ok.

-Original Message-
From: Raúl Carazo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 27, 2001 10:22 AM
To: [EMAIL PROTECTED]
Subject: RE: Fonts


But I'm using it from a servlet. And I do call to the userconfig file. This
file contains a line like this:
font metrics-file=complete Path for the verdana.xml file kerning=yes
embed-file=
   font-triplet name=Verdana style=normal weight=normal/
  /font


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: Fonts

[Raúl Carazo]

Thanks to all of you, really!!

But I'm not using the example. In fact, if I try to use it, everything
works, but when I move it to my servlet...
It's really strange, because if I set any font, it appears with Times New
Roman (the default one), but if I don't set it, it appears with Arial!!!

Anyway, thank you!

Salve

P.S. I send you the right xsl:

xsl:attribute-set name=style
  xsl:attribute name=font-size10pt/xsl:attribute
/xsl:attribute-set

With this style, the font is Arial

If I set this one:

xsl:attribute-set name=style
  xsl:attribute name=font-size10pt/xsl:attribute
  xsl:attribute name=font-familyVerdana/xsl:attribute
  xsl:attribute name=font-style/
/xsl:attribute-set

(with Verdana or any other font), the font is Times New Roman.

And if I set:

xsl:attribute-set name=style
  xsl:attribute name=font-size10pt/xsl:attribute
  xsl:attribute name=font-familyVerdana/xsl:attribute
/xsl:attribute-set

there is an exception.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Jeremias Maerki]

I take it you're talking about an Adobe Type 1 font, right? There are a
few known issues with the generation of XML metric files in PFMReader
with exotic fonts. This means sometimes a wrong value for Flags is set.
If you have Acrobat (not Acorbat Reader), you could generate a PDF from
a Word processor with your Cosmic font. Then open the generated PDF in a
text editor and look for /Flags (and Cosmic of course). Immediately
after this tag you'll find a number which you should use in the XML
metrics file generated for your font.

A more technical approach would be to have a look at chapter 7.11.2
font descriptor flags to play with the various flags. The value of the
Flags attribute depends on the font. There are different values for
normal fonts such as Helvetica and for symbol fonts such as
ZapfDingbats.

If it doesn't work out this way, you should state what kind of font it
is you're using and what value PFMReader generated for Flags. I may
then be able to give a few values you could try out.

On Wed, 31 Oct 2001 15:26:04 +0100 Thomas Kübler wrote:
 i have a problem printing a pdf with integrated a new font.
 i have no problem to render with fop20.1 the job. the result
 is a pdf-file where the new font is embedded. when i opend
 the pdf-file in acrobat 4.0 he always told me 
 In the font 'Cosmic' is the value for /Flags wrong. when i printed the job
 the result are white paper.

Cheers,
Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Fonts and reporting classes

[Tore Engvig]

On Fri, 17 Aug 2001, Spectron Caribe, Inc. wrote:

 Ok, thanks for the info. One more thing and I'll leave you guys alone. :)

 I think that java.awt.Font has almost all the information needed to create a
 /FontDescriptor. Would it be posible to create an XML file using a
 java.awt.Font class? For example.

 createXMLFont(java.awt.Font f).

 I think it would be useful. If the font found in the Java environment
 (Arial, Times, ...) is found in the system it will use it, if not it will
 use one of the standard fonts.

It has almost all you need, but not all you need. E.g. it's not possible
to determine what kind of font it is (postscript, truetype, etc)

Also, it would be of limited use.

* Using awt fonts would require a peer (as far as I know).
* You can only use one of the predefined encodings (winansi, macroman).
  You can't use other unicode characters as that would require knowledge
  of the glyph indexes in the font.
* You can't be sure that the fonts available to java is available as a
  system font. In unix environments you can almost be sure that a java
  font is not available as a system font.


Tore


 Faw

 - Original Message -
 From: Jeremias Maerki [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Friday, August 17, 2001 2:31 AM
 Subject: Re: Fonts and reporting classes


 On Thu, 16 Aug 2001 15:28:58 -0400 Spectron Caribe, Inc. wrote:
  1. I know that in PDF files you can add a /FontDescriptor for a TrueType
  font without actually embedding the font. What this does is if the font is
  found in the system it uses it, if not it uses another font. Is there any
  way I could do that with FOP?

 Try removing the embed-file attribute from the font-metrics in the
 userconfig.xml.

 Jeremias Märki

 mailto:[EMAIL PROTECTED]

 OUTLINE AG
 Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
 Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
 Internet http://www.outline.ch


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Fonts and reporting classes

[Jeremias Maerki]

On Thu, 16 Aug 2001 15:28:58 -0400 Spectron Caribe, Inc. wrote:
 1. I know that in PDF files you can add a /FontDescriptor for a TrueType
 font without actually embedding the font. What this does is if the font is
 found in the system it uses it, if not it uses another font. Is there any
 way I could do that with FOP?

Try removing the embed-file attribute from the font-metrics in the
userconfig.xml.

Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Fonts and reporting classes

[Alex McLintock]

 --- Arved Sandstrom [EMAIL PROTECTED] wrote:  
 4. Just for curiosity, why isn't there a HTMLRenderer?
 
 Lack of interest? I wouldn't recommend production of HTML from FO myself.
 

I expect that most people follow the strategy of Cocoon and similar systems.
They have their source data in their own XML format. This is converted to
html for the website  by XSLT or something similar, and separately to XSL:FO for
processing by FOP. 

So usually no FO to HTML renderer is required. 

FO is optimised for describing pages - like laser printer pages, and so fo to html
wouldn't look very good.

Of course you could implement an entire website just out of PDF pages :-)

Alex


=
Alex McLintock[EMAIL PROTECTED]Open Source Consultancy in London
OpenWeb Analysts Ltd, http://www.OWAL.co.uk/ 
SF and Computing Book News and Reviews: http://news.diversebooks.com/
Get Your XML T-Shirt t-shirt/ at http://www.inversity.co.uk/


Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Fonts and reporting classes

[Spectron Caribe, Inc.]

Ok, thanks for the info. One more thing and I'll leave you guys alone. :)

I think that java.awt.Font has almost all the information needed to create a
/FontDescriptor. Would it be posible to create an XML file using a
java.awt.Font class? For example.

createXMLFont(java.awt.Font f).

I think it would be useful. If the font found in the Java environment
(Arial, Times, ...) is found in the system it will use it, if not it will
use one of the standard fonts.

Faw

- Original Message -
From: Jeremias Maerki [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 17, 2001 2:31 AM
Subject: Re: Fonts and reporting classes


On Thu, 16 Aug 2001 15:28:58 -0400 Spectron Caribe, Inc. wrote:
 1. I know that in PDF files you can add a /FontDescriptor for a TrueType
 font without actually embedding the font. What this does is if the font is
 found in the system it uses it, if not it uses another font. Is there any
 way I could do that with FOP?

Try removing the embed-file attribute from the font-metrics in the
userconfig.xml.

Jeremias Märki

mailto:[EMAIL PROTECTED]

OUTLINE AG
Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: Fonts and reporting classes

[Arved Sandstrom]

At 03:28 PM 8/16/01 -0400, Spectron Caribe, Inc. wrote:
3. If I have a fo:block with a few fo:inline's with different font sizes is
there a way to make the line auto-size to the largest font in the line?

This is a major thing we need to do when we address line area improvements. 
Hopefully that is not far off.

4. Just for curiosity, why isn't there a HTMLRenderer?

Lack of interest? I wouldn't recommend production of HTML from FO myself.

Regards,
Arved Sandstrom

Fairly Senior Software Type
e-plicity (http://www.e-plicity.com)
Wireless * B2B * J2EE * XML --- Halifax, Nova Scotia


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

RE: fonts

[Wolf Gustavo (SGC-EXT)]

Thanks for the tip Rajeev,
Gustavo

-Message d'origine-
De : rajeev nair [mailto:[EMAIL PROTECTED]]
Envoye : lundi, 16. juillet 2001 07:18
A : [EMAIL PROTECTED]
Objet : Re: fonts


hello
why don't u make ur own font metric xml file for
arial?
You can make it from ttf files easily by using the
class TTFReader in fop.
regards
rajiv

--- Wolf Gustavo (SGC-EXT) [EMAIL PROTECTED]
wrote:
 Hi all,
 has someone implemmented Arial and
 Arial-italics?
 If the answer is yes, could I get the corresponding
 files?
 
 Also, does Helvetica (what I am replacing Arial
 with) have italics?
 
 Thanks once more,
  Gustavo
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, email:
 [EMAIL PROTECTED]
 


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Hoang Nam]

Hello,

When you use the fonts embbedded ( with metric files), do you increase the
size of the file , don't you ?

Nam


- Original Message -
From: rajeev nair [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, July 16, 2001 7:18 AM
Subject: Re: fonts


 hello
 why don't u make ur own font metric xml file for
 arial?
 You can make it from ttf files easily by using the
 class TTFReader in fop.
 regards
 rajiv

 --- Wolf Gustavo (SGC-EXT) [EMAIL PROTECTED]
 wrote:
  Hi all,
  has someone implemmented Arial and
  Arial-italics?
  If the answer is yes, could I get the corresponding
  files?
 
  Also, does Helvetica (what I am replacing Arial
  with) have italics?
 
  Thanks once more,
   Gustavo
 
 
 -
  To unsubscribe, e-mail:
  [EMAIL PROTECTED]
  For additional commands, email:
  [EMAIL PROTECTED]
 


 __
 Do You Yahoo!?
 Get personalized email addresses from Yahoo! Mail
 http://personal.mail.yahoo.com/

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, email: [EMAIL PROTECTED]


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[Petr Andrs]

Yes, fonts are stored in PDF file so it is bigger. But there is no 
other way how to display glyphs which are not included in standard 
fonts supplied with acrobat reader.

pa

On 25 Jul 2001, at 14:50 Hoang Nam wrote about Re: fonts :

 Hello,
 
 When you use the fonts embbedded ( with metric files), do you increase
 the size of the file , don't you ?
 
 Nam
 
 - Original Message -
 From: rajeev nair [EMAIL PROTECTED]
 
  hello
  why don't u make ur own font metric xml file for
  arial?
  You can make it from ttf files easily by using the
  class TTFReader in fop.
  regards
  rajiv
 
  --- Wolf Gustavo (SGC-EXT) [EMAIL PROTECTED]
  wrote:
   Hi all,
   has someone implemmented Arial and
   Arial-italics?
   If the answer is yes, could I get the corresponding
   files?
  
   Also, does Helvetica (what I am replacing Arial
   with) have italics?
  
   Thanks once more,
  Gustavo


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Re: fonts

[rajeev nair]

hello
why don't u make ur own font metric xml file for
arial?
You can make it from ttf files easily by using the
class TTFReader in fop.
regards
rajiv

--- Wolf Gustavo (SGC-EXT) [EMAIL PROTECTED]
wrote:
 Hi all,
 has someone implemmented Arial and
 Arial-italics?
 If the answer is yes, could I get the corresponding
 files?
 
 Also, does Helvetica (what I am replacing Arial
 with) have italics?
 
 Thanks once more,
  Gustavo
 

-
 To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, email:
 [EMAIL PROTECTED]
 


__
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]