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: can't find default configuration file

[Clay Leeds]

Andreas wrote:
Hi Maestro,
Upon checking fop.sh and fop.bat, I don't think there's much you can do
there... if you decide to add a possible FAQ about it, make sure it 
tells
people to use quoted arguments in case of characters like these in the
paths. Works on OS X and Win2K. The shell scripts interpret these as 
one
argument, and pass them as such to FOP.
Thanks for the heads up, Andreas. I'll keep that in mind. Does this 
mean one should do something like this for Unix:

./fop.sh -d -c "/my weird/conf path!/userconfig.xml" -fo input.fo -pdf 
t.pdf

or or this for Windows:
./fop.bat -d -c "c:\my weird\conf path!\userconfig.xml" -fo input.fo 
-pdf t.pdf

Thanks!
BTW, Anyone else seeing sporadic mail issues? I didn't actually 
*receive* Andreas' message. (I noticed in MARC, and am responding 
before I go home).

Web Maestro Clay

Re: Justification and line breaking

[Peter B. West]

Glen Mazza wrote:
--- Simon Pepping <[EMAIL PROTECTED]> wrote:
Errr--I wouldn't want additional branches in CVS just
for the sake of a patch--they tend to become
permanent.  Luca working on his local machine, or
using something on SourceForge may be a better idea. 
It's just Monday right now--we can wait a few more
days.
Glen, branches are only as permanent as you make them.  They're a tool, 
and with the CVS-aware IDEs out there, they are increasingly easy to 
use.  (Until we're Subverted, anyway.  Not a comment on the product 
itself, just the expected level of third-party support.)

Peter
--
Peter B. West 

Re: Justification and line breaking

[Peter B. West]

Simon Pepping wrote:
...
I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?
If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.
Simon, yes!  That's what branching is there for.  People seem to be 
afraid of it, but it is an enormously useful tool for just such 
situations.  I think it's always a good idea to tag the tree immediately 
before a branch.

Peter
--
Peter B. West 

[GUMP@brutus]: xml-fop/xml-fop prerequisite failed

[Sam Ruby]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project xml-fop *no longer* has an issue.
Project State : 'Prerequisite Failed', Reason 'Build Failed'

Full details are available at:

http://brutus.apache.org:8080/gump/xml-fop/xml-fop/index.html

That said, some snippets follow:


The following annotations were provided:
 -INFO- Sole jar [fop.jar] identifier set to project name
 -INFO- Prerequisite failed with reason build failed



To subscribe to this information via syndicated feeds:
 RSS: http://brutus.apache.org:8080/gump/xml-fop/xml-fop/rss.xml
 Atom: http://brutus.apache.org:8080/gump/xml-fop/xml-fop/atom.xml


--
Produced by Gump 2.0.3-alpha-0002.
[Run (20040524 15:00:12, brutus:brutus-public:20040524 15:00:12)]
http://brutus.apache.org:8080/gump/index.html
http://brutus.apache.org:8080/gump/options.html

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

[GUMP@brutus]: xml-fop-maintenance/xml-fop-maintenance prerequisite failed

[Sam Ruby]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact folk at [EMAIL PROTECTED]

Project xml-fop-maintenance *no longer* has an issue.
Project State : 'Prerequisite Failed', Reason 'Build Failed'

Full details are available at:


http://brutus.apache.org:8080/gump/xml-fop-maintenance/xml-fop-maintenance/index.html

That said, some snippets follow:


The following annotations were provided:
 -INFO- Sole jar [fop.jar] identifier set to project name
 -INFO- Prerequisite failed with reason build failed



To subscribe to this information via syndicated feeds:
 RSS: 
http://brutus.apache.org:8080/gump/xml-fop-maintenance/xml-fop-maintenance/rss.xml
 Atom: 
http://brutus.apache.org:8080/gump/xml-fop-maintenance/xml-fop-maintenance/atom.xml


--
Produced by Gump 2.0.3-alpha-0002.
[Run (20040524 15:00:12, brutus:brutus-public:20040524 15:00:12)]
http://brutus.apache.org:8080/gump/index.html
http://brutus.apache.org:8080/gump/options.html

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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 

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: Justification and line breaking

[Glen Mazza]

--- Simon Pepping <[EMAIL PROTECTED]> wrote:
Chris wrote:
>  
> > Is anyone else on the team planning on making
> large commits over the next 
> > couple of days? I would be grateful if you could
> hold off for a couple of 
> > days whilst the problems with this large patch are
> resolved. I dont want to 
> > have to re-apply the changes. Let me know if this
> causes any problems
> 

OK--I'll hold off myself.  But from my experience
working with Finn's several huge patches, applying
these things incrementally can work wonders.

> If I see it right, then Luca should work on his
> patch some
> more. 

Sounds like it, from Chris' explanation.

> Perhaps others could help with that work if he
> would want
> that. In such a situation it may be a good strategy
> to commit the
> patch to a branch of the HEAD of the trunk, so that
> it can be
> developed without problems with other work.
> 

Errr--I wouldn't want additional branches in CVS just
for the sake of a patch--they tend to become
permanent.  Luca working on his local machine, or
using something on SourceForge may be a better idea. 
It's just Monday right now--we can wait a few more
days.

Glen

Re: Fixing break-* properties

[arnd . beissner]

"Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote on 24.05.2004 
21:49:48:

> There are, AFAICT only 4 types of FO to which break-before and 
break-after
> apply:
> - block level: fo:block / fo:block-container
> - fo:list-item
> - fo:table-row

For completeness, add:
- fo:table-and-caption
- fo:table

Maybe this can always be aggregated into a break property on the first
table row, but I'm not 100% sure of that yet.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

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: Justification and line breaking

[Simon Pepping]

Chris,

On Mon, May 24, 2004 at 01:57:34PM +0100, Chris Bowditch wrote:
> Hi Luca,
> 
> I have managed to apply your patch. Testing has not gone well. Firstly, I 
> had trouble compiling, due to BLM using the old constructor for LLM with 
> FObj as the first argument. This is easily corrected, but I would have 
> expected a change to BLM in your patch file. Also I found a few calls to 
> getLogger in the LMs, which dont compile. I hit the problem of not being 
> able to call getLogger in the LM code myself recently. So I added a 
> getLogger method to AbstractLM.

I changed the constructor call as well. I changed the logger calls
from getLogger() to log. log is a member of
AbstractLayoutManager. These are changes applied by Glen, and
apparently Luca made his diff before they were applied.
 
> Once compiled I tried testing with a complex document, but that fell over. 
> Previously it was working, albeit without markers. I then tried one of your 
> more simple test cases and that fell over too. Here is the stack trace, 
> which is the same for both documents:
> 
> Exception in thread "main" java.lang.NullPointerException
> at 
> org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
> ineLayoutManager.java:249)
> at 
> org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
> tManager.java:351)
> at 
> org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
> outManager.java:202)
> 
> Any thoughts would be appreciated.

No exceptions. I ran Luca's test fo files successfully.

Note that the test files erroneously specify the language as "eng";
this should be "en".

I am not surprised that your complex document did not run well. If I
understand the situation well, then the patch works for LineLM with
TextLM childLMs. It does not work with any other childLM. I expect the
other childLMs to use the null implementation of getNextKnuthElement()
and therefore to contribute no areas. This does not explain that it
causes an exception, though.
 
> Is anyone else on the team planning on making large commits over the next 
> couple of days? I would be grateful if you could hold off for a couple of 
> days whilst the problems with this large patch are resolved. I dont want to 
> have to re-apply the changes. Let me know if this causes any problems

I do not believe that the patch is mature for committing to the trunk
code. See above. Luca, do you share my view?

If I see it right, then Luca should work on his patch some
more. Perhaps others could help with that work if he would want
that. In such a situation it may be a good strategy to commit the
patch to a branch of the HEAD of the trunk, so that it can be
developed without problems with other work.

Regards, Simon

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

Fixing break-* properties

[Andreas L. Delmelle]

Hi,

In attempting to fix the break-before and break-after properties, I noticed
two methods that are commented out in PropertyManager, checkBreakBefore()
and checkBreakAfter() --used in maintenance branch to keep track of possibly
enforced page- or column-breaks.

I can only assume that the intention is that eventually the logic gets moved
out of the PropertyManager, and into the PageLM/FlowLM, via the
childLM.getNextBreakPoss() method and the LayoutManagers corresponding to
the FObjs that have these properties.
There are, AFAICT only 4 types of FO to which break-before and break-after
apply:
- block level: fo:block / fo:block-container
- fo:list-item
- fo:table-row

Adding the necessary activation code to the FObjs to pass these properties
to Layout is easy enough, but I'm still having a bit of difficulty in
'seeing' what needs to be done to handle this in the respective LMs
getNextBreakPoss()... How is LayoutContext involved in this (or isn't it)?


Anybody with a keen eye for these things?

TIA!

Andreas

RE: Justification and line breaking

[Andreas L. Delmelle]

> -Original Message-
> From: Chris Bowditch [mailto:[EMAIL PROTECTED]

Hi Chris,


> Is anyone else on the team planning on making large commits over the next
> couple of days? I would be grateful if you could hold off for a
> couple of days
> whilst the problems with this large patch are resolved. I dont
> want to have to
> re-apply the changes. Let me know if this causes any problems
>

Not me, for the moment... The table-related adjustment turns out to be a bit
more complicated than I initially thought. (have a few other questions
regarding this, but these are going into a separate thread)


Cheers,

Andreas

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

[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

[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]

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: Justification and line breaking

[Chris Bowditch]

Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I had
trouble compiling, due to BLM using the old constructor for LLM with FObj as
the first argument. This is easily corrected, but I would have expected a
change to BLM in your patch file. Also I found a few calls to getLogger in the
LMs, which dont compile. I hit the problem of not being able to call getLogger
in the LM code myself recently. So I added a getLogger method to AbstractLM.
Once compiled I tried testing with a complex document, but that fell over.
Previously it was working, albeit without markers. I then tried one of your
more simple test cases and that fell over too. Here is the stack trace, which
is the same for both documents:
Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
Is anyone else on the team planning on making large commits over the next
couple of days? I would be grateful if you could hold off for a couple of days
whilst the problems with this large patch are resolved. I dont want to have to
re-apply the changes. Let me know if this causes any problems
Chris

Re: Justification and line breaking

[Chris Bowditch]

Hi Luca,
I have managed to apply your patch. Testing has not gone well. Firstly, I had 
trouble compiling, due to BLM using the old constructor for LLM with FObj as 
the first argument. This is easily corrected, but I would have expected a 
change to BLM in your patch file. Also I found a few calls to getLogger in the 
LMs, which dont compile. I hit the problem of not being able to call getLogger 
in the LM code myself recently. So I added a getLogger method to AbstractLM.

Once compiled I tried testing with a complex document, but that fell over. 
Previously it was working, albeit without markers. I then tried one of your 
more simple test cases and that fell over too. Here is the stack trace, which 
is the same for both documents:

Exception in thread "main" java.lang.NullPointerException
at org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L
ineLayoutManager.java:249)
at org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou
tManager.java:351)
at org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay
outManager.java:202)
Any thoughts would be appreciated.
Is anyone else on the team planning on making large commits over the next 
couple of days? I would be grateful if you could hold off for a couple of days 
whilst the problems with this large patch are resolved. I dont want to have to 
re-apply the changes. Let me know if this causes any problems

Chris

Re: Fonts

[Jeremias Maerki]

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?

On 24.05.2004 07:20:05 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. 
> 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...


Jeremias Maerki

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 

RE: Fonts

[arnd . beissner]

"Victor Mote" <[EMAIL PROTECTED]> schrieb am 24.05.2004 02:32:28:

> 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.
> 
> ...
> 
> No. Font *embedding* is renderer specific. AFAICT, everything else about 
the
> font is the same.
> 
> ...
>
> 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.
> 
> ...
> 
> 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.

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.

My 2 cents.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

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]

Victor Mote wrote:
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.
I don't know; I'm new to Java font handling myself.  Another disclaimer; 
I haven't considered the issue of embedding.  That said, I don't see a 
way to get to a physical font.

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.
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.

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)
FontMetrics *seems* to have been bypassed in the latest font handling. 
The methods that are being used in the 2D tutorials focus on 
LineMetrics, i.e. the metrics of particular pieces of text.  LineMetrics 
can be obtained directly from the Font, the text concerned, and the 
FontRenderContext, which is based on the AffineTransform (if any), and 
whether the rendering is anti-aliased or uses fractional metrics.  The 
text concerned can be a String or a CharacterIterator, providing access 
to character attributes.  Also available directly from Font are 
java.awt.font.GlyphVectors and the layoutGlyphVector method, which does 
bi-directional layout.

In addition, in java.awt.font are TextAttribute, TextLayout, 
LineBreakMeasurer, TextMeasurer and GlyphMetrics.  LineMeasurer is of 
limited utility, because it only implements a default line break policy, 
but TextMeasurer allows much finer control.  GlyphMetrics seems to be 
the preferred direction for layout measurement, giving precise 
dimensions for glyphs in a particular piece of text, laid out in a 
particular FontRenderContext.

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.
I agree.

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 t

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