Re: Collapsing borders/Tables: Knuth element generation questions (possible ideas?)

[Jeremias Maerki]

On 20.09.2005 23:50:12 Andreas L Delmelle wrote:
> Hi,
> 
> Jeremias, Luca or Simon will probably be able to make the most sense 
> out of it, but if there's anyone else that can add a few comments, feel 
> free to do so.
> (FYI: This is completely separate from my idea to move the 
> border-collapsing to the FOTree.)
> 
> Now, I'm still not fully at home in the Knuth element generation 
> algorithm, so I don't know exactly whether what I'm about to describe 
> is at all feasible/doable. Maybe it's currently already done this way, 
> and I'm missing the point somewhere... In that case: sorry for the 
> noise. :-/
> 
> Here goes:
> I get the impression that the elements for borders and those for the 
> content of the cells are created in one single pass, which seems to be 
> the source of the so-called 'interaction problem' --IIC, this refers to 
> the situation where, for example, we have already generated the AFTER 
> border elements for the first two cells, while it's only when 
> generating the elements for the third cell that a break is triggered. 
> So, the obtained border- and content-elements become invalid, and need 
> to be re-evaluated (possibly taking the footer into account).
> Is this a correct assessment of the issue?

Unfortunately not. I get the impression that you haven't understood, yet,
how the Knuth approach works. We don't reevaluate any decisions in this
approach, but rather calculate ALL(!) possible decisions beforehand and
incorporate them into the element list we generate. The breaker will
merely choose a break possibility and the addAreas stage will paint the
results given the break decision. The only reevaluation will happen if
we start to implement support for the "changing available IPD" problem,
i.e. when the available IPD is different from page to page within the
same page-sequence. In this case we will need to be able to recreate the
element list from an arbitrary former break possibility on forward which
means that all decisions are reevaluated from this point on due to
changed environmental factors (the IPD). Even the line-breaking has to
be redone, although the inline element list will not have to be
recreated.

This calculation of all possible decisions when generating the element
list is exactly the same problem I'm currently facing with space
resolution. I have to precalculate all space resolution scenarios for
every single break possibility in order to be able to create the right
element list. Mind-breaking, I tell you.. :-)

> Am I correct when I say that this problem doesn't pose itself when the 
> break would occur in the first cell of the row(group)?
>
> If so, I'm wondering whether it could help if the element generation 
> for row(groups) were split up in two (possibly three passes) and be 
> made to look like the following (in pseudo-code):
> 
> while( rowIterator.hasNext() ) {
>if( firstRowGroupInPageOrColumn ) {
>  generateBeforeBorderElements();
>}
>generateAfterBorderElements();
>generateContentElements();
> }
> 
> So, by the time we get to generating boxes/glues/penalties for the 
> content of the cells, we would already have the minimum/maximum widths 
> for *all* possible AFTER border elements in the row.
> The generateAfterBorderElements() step would create two element lists:
> - one to use if there is no page- or column-break
> - an alternate list to use in case the content triggers a break (which 
> would then include all elements for the footer, if any)

I don't think something like that is possible. During my analysis I
found that the effective borders influence the Knuth element generation
a lot. You can't separate the borders from the content. Have a look at
the notes in the Wiki. They show this interaction. It's all documented
there. The element list generation is fully implemented for the separate
border model. For the collapsing border model, several examples are
documented and fully calculated. The only thing left is the algorithm to
handle all the little difficulties arising from the collapsing border
model. The most important pages for implementing the collapsing border
model are these:
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/RowBorder2
http://wiki.apache.org/xmlgraphics-fop/TableLayout/KnuthElementsForTables/HfIntegrationInSteppingAlgorithm

> Maybe both lists could be made to include the elements for the AFTER 
> padding as well (? since we have to iterate over the cells/grid-units 
> anyway).
> 
> Eventually only one of the two lists will be merged with the content 
> element list, depending on the situation after the content element list 
> completely known, but it would become a matter of inserting the right 
> list (and discarding the incorrect one --at least, throwing away its 
> elements).
> 
> The only drawback I immediately see is that the 
> generateAfterBorderElements() step would have to 

Re: Column-numbers: pending issues discovered

[Andreas L Delmelle]

On Sep 21, 2005, at 00:22, Andreas L Delmelle wrote:


Hi,

If anyone should feel a need to try out the following scenarios:

- combined column- and row-span on cells in a table with explicit 
columns: if the cell spans more than one column and there is an 
unoccupied column-number in between


- cells as direct descendants of table-body in a table with explicit 
columns: if there is a row with more than (number-of-columns + 1) 
cells --there is already a testcase for (number-of-columns + 1). Try 
adding one more, and...


False alarm for the second case. The first will give errors...


Andreas

Column-numbers: pending issues discovered

[Andreas L Delmelle]

Hi,

If anyone should feel a need to try out the following scenarios:

- combined column- and row-span on cells in a table with explicit 
columns: if the cell spans more than one column and there is an 
unoccupied column-number in between


- cells as direct descendants of table-body in a table with explicit 
columns: if there is a row with more than (number-of-columns + 1) cells 
--there is already a testcase for (number-of-columns + 1). Try adding 
one more, and...


The message is: DON'T -not just yet. These will still lead to 
'overlap-errors'.


This post just to let you know I'm working on it. Coming very soon.


Cheers,

Andreas

Collapsing borders/Tables: Knuth element generation questions (possible ideas?)

[Andreas L Delmelle]

Hi,

Jeremias, Luca or Simon will probably be able to make the most sense 
out of it, but if there's anyone else that can add a few comments, feel 
free to do so.
(FYI: This is completely separate from my idea to move the 
border-collapsing to the FOTree.)


Now, I'm still not fully at home in the Knuth element generation 
algorithm, so I don't know exactly whether what I'm about to describe 
is at all feasible/doable. Maybe it's currently already done this way, 
and I'm missing the point somewhere... In that case: sorry for the 
noise. :-/


Here goes:
I get the impression that the elements for borders and those for the 
content of the cells are created in one single pass, which seems to be 
the source of the so-called 'interaction problem' --IIC, this refers to 
the situation where, for example, we have already generated the AFTER 
border elements for the first two cells, while it's only when 
generating the elements for the third cell that a break is triggered. 
So, the obtained border- and content-elements become invalid, and need 
to be re-evaluated (possibly taking the footer into account).

Is this a correct assessment of the issue?
Am I correct when I say that this problem doesn't pose itself when the 
break would occur in the first cell of the row(group)?


If so, I'm wondering whether it could help if the element generation 
for row(groups) were split up in two (possibly three passes) and be 
made to look like the following (in pseudo-code):


while( rowIterator.hasNext() ) {
  if( firstRowGroupInPageOrColumn ) {
generateBeforeBorderElements();
  }
  generateAfterBorderElements();
  generateContentElements();
}

So, by the time we get to generating boxes/glues/penalties for the 
content of the cells, we would already have the minimum/maximum widths 
for *all* possible AFTER border elements in the row.

The generateAfterBorderElements() step would create two element lists:
- one to use if there is no page- or column-break
- an alternate list to use in case the content triggers a break (which 
would then include all elements for the footer, if any)


Maybe both lists could be made to include the elements for the AFTER 
padding as well (? since we have to iterate over the cells/grid-units 
anyway).


Eventually only one of the two lists will be merged with the content 
element list, depending on the situation after the content element list 
completely known, but it would become a matter of inserting the right 
list (and discarding the incorrect one --at least, throwing away its 
elements).


The only drawback I immediately see is that the 
generateAfterBorderElements() step would have to make the comparison 
with the footer- or table-borders for each and every row, unless we 
were to do this only in case the remaining page- or column-BPD has 
dropped below a certain threshold.


The only remaining problems would then be that:
a) there may be row(groups) whose content is so large that the 
remaining BPD is more than enough before the content's elements are 
generated, but only drops below the threshold during the 
generateContentElements() step.
b) there's always the possibility of a forced break, regardless of the 
remaining BPD


The creation of the alternate element list should therefore be 
implemented as a separate step that can be triggered either during 
generateAfterBorderElements() or generateContentElements().


In any case, besides gaining certainty about min- or max-border-widths, 
splitting up the element generation in 2-3 passes would allow us to 
gain a few hints on the content to get an idea of the probability of a 
page- or column-break.
I mean: without actually triggering creation of a full element list for 
the content, we could maybe do a quick traverse of the FOTree-fragment 
contained in each cell to see if any of its descendants have a break-* 
property specified.
To make an even more educated guess, perhaps we could even perform some 
off-hand calculations based on the average font-size, the number of 
blocks, the number of characters of the descendant FOText nodes, the 
content-height for contained images... But this all *without* 
generating the elements. Only minimal communication with the actual 
childLMs in that step, placing the focus on the FONode-elements (= the 
list returned by TableCell.getChildNodes()) and their properties.



Does this make any sense?


Cheers,

Andreas

Re: rtf ignoring TableBody et al

[Jeremias Maerki]

On 20.09.2005 17:50:03 Matthew L Daniel wrote:
> > The warning is an indicator that there are still a few things in RTF
> > support that need fixing.
> 
> So is there someone who owns this class? 

No. There are no class owners in Apache projects.

> How long has it been
> out-of-sync - that is, is it in the same condition as TXTRenderer?

The TXTRenderer has not been implemented after the redesign. The RTF
support was added by integrating JFOR. The RTF support works reasonably
well for many use cases but most probably not all. It's still
alpha-grade code like the rest of the redesigned FOP.

> Also, while this is probably not the correct forum for this question,
> what has been the reference tool for checking the RTF output?

The RTF support is mainly for MS Word. I use the MS Word 2003 Viewer.

> OpenOffice.org 2.0 beta won't even correctly render the SimpleTable from
> jfor. Since Word Viewer 2003 does, I'm inclined to think it's an OOo
> bug more than a jfor bug.

OpenOffice is horrible when it comes to RTF. We'd better create a
develop FOEventHandler for the new OpenDocument format if someone wants
to open FOP-generated documents in OpenOffice.

> However, I hope this he-said-she-said
> illustrates my correctness concern for the RTF output.

I don't understand what you mean. Probably a foreign language parse
error on my side. :-)


Jeremias Maerki

AW: rtf ignoring TableBody et al

[Peter Herweg]

Yes, there are few nodes types missing, because i just added the node types,
which are implemented in rtf module.
But you are right: TableBody is implemented, but is missing in the
if-structure. I'll add it.

There is also support for ExternalGraphics, but i guess this won't work so i
did not add it to if-structure. This will be my next task in rtf module.

Regards,
Peter Herweg

-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Auftrag von Andreas L Delmelle
Gesendet: Dienstag, 20. September 2005 00:58
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: rtf ignoring TableBody et al


On Sep 20, 2005, at 00:28, Matthew L Daniel wrote:

> I am using trunk code and with an input FO that produces excellent PDF
> output, I am seeing the following messages about lots of ignored
> instances.
>
> After checking RTFHandler.java, it seems they are omitted from the very
> large instance-switch in "invokeDeferredEvent".
>
> My question is if this is "in progress" code or if RTFHandler has been
> broken like this for a while?

Seems like it's broken. At least, there's a few node-types missing,
amongst which precisely TableBody, TableHeader, TableFooter,
InstreamForeignObject, SVGElement, ExternalGraphic...

I'm going to leave this for now, since I don't know too much about the
RTF Rendering code --maybe those node-types were left out for a good
reason, I'm not sure.

At first glance, the whole structure:

if( fo instanceof PageSequence ) {
   //do something
} else if( fo instanceof Flow ) {
   //do something
} ...

would probably better be replaced by one

switch( fo.getNameId() ) {
case Constants.FO_PAGE_SEQUENCE:
   //do something
   break;
case Constants.FO_FLOW:
   //do something
   break;
   ...
}

The least this would do is avoid a number of unnecessary calls to
instanceof.

Note to Peter Herweg: I think I see now what you meant by the many
'if-then-else-if's. I hope you can put the above comment to good use...


Cheers,

Andreas

AW: rtf ignoring TableBody et al

[Peter Herweg]

I am checking the rtf results with Word 2000 SP3.

Regards,
Peter Herweg

-Ursprungliche Nachricht-
Von: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Auftrag von Matthew L Daniel
Gesendet: Dienstag, 20. September 2005 17:50
An: fop-dev@xmlgraphics.apache.org
Betreff: Re: rtf ignoring TableBody et al


> The warning is an indicator that there are still a few things in RTF
> support that need fixing.

So is there someone who owns this class? How long has it been
out-of-sync - that is, is it in the same condition as TXTRenderer?

Also, while this is probably not the correct forum for this question,
what has been the reference tool for checking the RTF output?
OpenOffice.org 2.0 beta won't even correctly render the SimpleTable from
jfor. Since Word Viewer 2003 does, I'm inclined to think it's an OOo
bug more than a jfor bug. However, I hope this he-said-she-said
illustrates my correctness concern for the RTF output.

  -- /v\atthew

AW: rtf ignoring TableBody et al

[Peter Herweg]

Jeremias Maerki wrote:
> I added the warning because I found a case where a block-container
> wasn't handled as it should have been:
> http://svn.apache.org/viewcvs?rev=278720&view=rev

Good idea, in my opinion.

Regards,
Peter Herweg

Re: rtf ignoring TableBody et al

[Andreas L Delmelle]

On Sep 20, 2005, at 17:40, Matthew L Daniel wrote:

Hi Matthew,


The least this would do is avoid a number of unnecessary calls to
instanceof.


You're on the right track, and maybe that "switch" impl would be an
80/20 win over the cost of the Right Way. But that huge if-instance 
case

is exactly what the Visitor pattern was created to solve.


Yep! My remark was completely focused on that isolated part in one of 
the +600 source files. It just seemed like the more elegant way to deal 
with it --since the FONodes all have that getNameId() method, it makes 
more sense to call that once and compare the resulting int value to the 
constants, rather than checking the class for one node possibly so many 
times.
(Plus: using 'switch' offers the benefit of having fall-through cases, 
where you would need 'if-instanceof||instanceof||instanceof...')
As a personal note: I'd even like to replace all string-comparisons of 
the form 'fo.getName().equals("fo:something")' in the FOTree with 
'fo.getNameId() == FO_SOMETHING'. Not sure if that would save us much, 
but every little bit helps I guess. Even if both strings are 
internalized, 'int == int' outperforms 'String.equals(String)' by a 
significant factor (and that's still leaving small things like 
"fo:instream-foreign-object" [=26 Bytes] vs. FO_INSTREAM_FOREIGN_OBJECT 
[=4 Bytes] out of the picture)


'instanceof' itself can IMO only be put to good use in case of a 
complex class-hierarchy, where you can check for supertypes that each 
have lots-and-lots of subtypes, so 'x instanceof supertype' covers ten 
or more subtypes in one go.
Our FOTree isn't exactly suited for that kind of thing. Practically all 
the FOs are direct subclasses of FObj, and those that aren't, have at 
most one intermediate class in between...
(I've taken the liberty of adding one especially for the table-related 
FOs, since they share some functionality --still have to take a closer 
look at which members can be moved upward to TableFObj. For now, it's 
restricted to a few methods for dealing with the column-numbering and 
the border-precedences, but I'm almost certain that more can be made to 
follow.)


I haven't spent enough time with the Fop codebase to speak to the 
gains of such a

thing, but I'd bet RTFHandler isn't the only one that does this.


Indeed not. FYI: FOP once did use the Visitor pattern for the 
layout-engine (over a year ago), but it was decided upon back then to 
remove it completely, mainly for reasons of keeping the code 
comprehensible for potential future committers IIRC.


A braindead `grep instanceof | wc -l` search shows 122 classes out of 
the

640 classes use instanceof, which in my world makes them at least worth
examination.


Depends a bit on *what* exactly they're checking and how many times 
they actually do that. If it's simple checks for FONode subtypes that 
are executed lots of times, these are indeed most likely suboptimal...



Another "implied" win to the Visitor interface is if a new FONode type
gets added, it forces the change to ripple (unless the impl is using 
the

DefaultVisitor) to all those who would need to handle the new
functionality.


... which indeed becomes of very much use once you start talking about 
FO Extension-elements.



Thanks for the valuable feedback --and for being one of our 
guinea-pigs, of course ;-)


Cheers,

Andreas

DO NOT REPLY [Bug 36720] - erroneous cell overlap code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36720


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 18:19 ---
The attached FO should work now. Still a few modifications pending WRT spanning 
cells in a table with 
unused column-numbers. Expect these later on (in an hour or so).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: rtf ignoring TableBody et al

[Matthew L Daniel]

> The warning is an indicator that there are still a few things in RTF
> support that need fixing.

So is there someone who owns this class? How long has it been
out-of-sync - that is, is it in the same condition as TXTRenderer?

Also, while this is probably not the correct forum for this question,
what has been the reference tool for checking the RTF output?
OpenOffice.org 2.0 beta won't even correctly render the SimpleTable from
jfor. Since Word Viewer 2003 does, I'm inclined to think it's an OOo
bug more than a jfor bug. However, I hope this he-said-she-said
illustrates my correctness concern for the RTF output.

  -- /v\atthew

Re: rtf ignoring TableBody et al

[Matthew L Daniel]

> The least this would do is avoid a number of unnecessary calls to 
> instanceof.

You're on the right track, and maybe that "switch" impl would be an
80/20 win over the cost of the Right Way. But that huge if-instance case
is exactly what the Visitor pattern was created to solve. I haven't
spent enough time with the Fop codebase to speak to the gains of such a
thing, but I'd bet RTFHandler isn't the only one that does this. A
braindead `grep instanceof | wc -l` search shows 122 classes out of the
640 classes use instanceof, which in my world makes them at least worth
examination.

Another "implied" win to the Visitor interface is if a new FONode type
gets added, it forces the change to ripple (unless the impl is using the
DefaultVisitor) to all those who would need to handle the new
functionality.

  -- /v\atthew

Next project:support for sub/superscripts

[Manuel Mall]

This is just a heads up on what I plan to do next. Having gained some 
familiarity with the inline LMs adding support for sub/superscripts 
seems like a useful feature to me. Actually the scope of this is a bit 
wider as to do that properly and not as a quick fix it involves support 
for the set of alignment properties (7.13) and the matching correct 
building of line areas (4.5) and inline areas (4.6).

I'll put my thoughts on this into a wiki page over the next few days.

Manuel

Re: text-altitude/-depth properties

[Finn Bock]

[Manuel]


This is probably a question for Finn.

I am looking into replacing the use font.getAscender() / 
font.getDescender() in the relevant LMs with the use of the appropriate 
properties text-altitude and text-depth. I would like to avoid having 
to write in all the LMs code like:


int textAltitude;
if (fobj.getTextAltitude().getEnum() == EN_USE_FONT_METRICS) {
   textAltitude = fobj.getCommonFont().getAscender();
} else {
   textAltitude = fobj.getTextAltitude().getValue(this);
}

What's the best way to move this sort of logic into the property system 
so the LMs only need to call:

textAltitude = fobj.getTextAltitude().getValue(this);
and the enum is resolved as part of the getValue call?


My gut feeling is that it should *not* be moved to the property system. 
Perhaps it should be placed in CommonFont which already has some of the 
intersection of properties and font state info. OTOH CommonFont is well 
defined and does not include text-altitude.


How about putting it on CommonFont as a static method:

static int getTextAltitude(Font font, Length textAltitude,
PercentBaseContext pbc) {
if (textAltitude.getEnum() == EN_USE_FONT_METRICS) {
return fs.getAscender();
} else {
return textAltitude.getValue(pbc);
}

Or perhaps it should be placed in a "FontHelper" class in layoutmgr.

regards,
finn

text-altitude/-depth properties

[Manuel Mall]

This is probably a question for Finn.

I am looking into replacing the use font.getAscender() / 
font.getDescender() in the relevant LMs with the use of the appropriate 
properties text-altitude and text-depth. I would like to avoid having 
to write in all the LMs code like:

int textAltitude;
if (fobj.getTextAltitude().getEnum() == EN_USE_FONT_METRICS) {
   textAltitude = fobj.getCommonFont().getAscender();
} else {
   textAltitude = fobj.getTextAltitude().getValue(this);
}

What's the best way to move this sort of logic into the property system 
so the LMs only need to call:
textAltitude = fobj.getTextAltitude().getValue(this);
and the enum is resolved as part of the getValue call?

Thanks

Manuel

DO NOT REPLY [Bug 36729] - Font metrics-url and embed-url are aways absolute, fails without good error message

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36729





--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 14:24 ---
Created an attachment (id=16460)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=16460&action=view)
Changes to enable logging when unable to find metrics file


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36720] - erroneous cell overlap code

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36720





--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 13:46 ---
Solved it, but unfortunately I can't commit the code from where I work, so 
expect the fix (and some other important modifications) in about 4-5 hours.
FWIW: the key is that I forgot one simple but *very* important line of code in 
org.apache.fop.fo.FOPropertyMapping.java -- below line 2390 the following 
should be added
m.setInherited(false);

Adding this should at least provide you with a temporary band-aid.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 36729] New: - Font metrics-url and embed-url are aways absolute, fails without good error message

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36729

   Summary: Font metrics-url and embed-url are aways absolute, fails
without good error message
   Product: Fop
   Version: 1.0dev
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: pdf renderer
AssignedTo: fop-dev@xmlgraphics.apache.org
ReportedBy: [EMAIL PROTECTED]


Under 1.0 the metrics-url and embed-url attribites of the  element are 
not relative to the specified base directory. 

Therefore they are loading from the working directory of the process (which is 
usually c:\windows\system32 if your server is running as a windows service).

Under 0.20 one was able to call:

org.apache.fop.configuration.Configuration.put
("fontBaseDir","/absolute/path/to/metrics/directory");

or put this in your configuration file.

Is is possible to add a way to specify a base directory for the font metric 
files, or make them relative to the configuration file itself. Otherwise one 
needs to encode system specific paths in the configuration file.

Also, this fails silently at the moment, and later on throws a null pointer 
error. Logging of the failure to load a metric file is labelled as todo. Since 
this is going to be a common error, a meaningful message will save users hours 
of trying to figure out what is happening

Attached is a patch file to log a meaningful error. Also I have moved the flag 
of successfull loading so that the flag is only set if they are really loaded.

Should the exception propogate up rather than swallowing it?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 21982] - NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=21982


[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|AIX |All




--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 13:07 ---
Under 0.20 you need to call:

org.apache.fop.configuration.Configuration.put
("fontBaseDir","/absolute/path/to/metrics/directory");

or put this in your configuration file. Otherwise the paths to the metrics and 
the fonts are relative to the current working directory, and you get this 
exception when it later tries to open them.

(You can also put absolute paths for the files).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 21982] - NullPointer Exception in LazyFont with embedded fonts (japanese fonts) in AIX

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=21982





--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 13:03 ---
Under 0.20 you need to call:

org.apache.fop.configuration.Configuration.put
("fontBaseDir","/absolute/path/to/metrics/directory");

or put this in your configuration file.

Otherwise it can't find the files and returns a null pointer error when it 
(later) tries to access them.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Sam Ruby]

To whom it may engage...

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

Project xml-fop-maintenance has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop-maintenance :  XSL-FO (Formatting Objects) processor (Maintenance 
branch)


Full details are available at:

http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html
Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-20092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-20092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-20092005.jar
-
Buildfile: build.xml

init-avail:

init-filters-jdk14:
 [echo] JDK 1.4 present.
 [copy] Copying 1 file to 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen

init-filters-jdk13:

init:
 [echo] --- Fop 0.20.5 [1999-2003] 

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apa

[EMAIL PROTECTED]: Project xml-fop-maintenance (in module xml-fop-maintenance) failed

[Sam Ruby]

To whom it may engage...

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

Project xml-fop-maintenance has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 15 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- xml-fop-maintenance :  XSL-FO (Formatting Objects) processor (Maintenance 
branch)


Full details are available at:

http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [fop.jar] identifier set to project name
 -INFO- Made directory 
[/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes]
 -INFO- Failed with reason build failed
 -DEBUG- Extracted fallback artifacts from Gump Repository



The following work was performed:
http://vmgump.apache.org/gump/public/xml-fop-maintenance/xml-fop-maintenance/gump_work/build_xml-fop-maintenance_xml-fop-maintenance.html
Work Name: build_xml-fop-maintenance_xml-fop-maintenance (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar
 org.apache.tools.ant.Main -Dgump.merge=/x1/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only gump 
[Working Directory: /usr/local/gump/public/workspace/xml-fop-maintenance]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/xml-fop-maintenance/build/classes:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-swing.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-css.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-bridge.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-xml.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-svg-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-awt-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-transcoder.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-gui-util.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-dom.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-ext.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-script.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-svggen.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-parser.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-extension.jar:/usr/local/gump/public/workspace/xml-batik/batik-20092005/lib/batik-gvt.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-20092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-20092005.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-20092005.jar
-
Buildfile: build.xml

init-avail:

init-filters-jdk14:
 [echo] JDK 1.4 present.
 [copy] Copying 1 file to 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/codegen

init-filters-jdk13:

init:
 [echo] --- Fop 0.20.5 [1999-2003] 

prepare:
 [echo] Preparing the build directories
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/fo/properties
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apache/fop/render/pdf/fonts
[mkdir] Created dir: 
/x1/gump/public/workspace/xml-fop-maintenance/build/src/org/apa

DO NOT REPLY [Bug 36677] - [PATCH] ant dist does not include serializer.jar

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=36677


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2005-09-20 12:12 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I'm already looking at build dist to include the docs ...
> 
> I don't follow this comment. "Docs?"

I just meant that I'm working at build.xml so I'm taking this patch.

> Perhaps most important to the bug report, does the command 'ant dist; mkdir 
> foo;
> tar xzf *-bin.tar.gz -C foo; sh foo/*/fop.sh -fo examples/fo/basic/simple.fo
-awt' 
> work for you? If so, do you have serializer*.jar in ${java.endosred.dirs}?

It works for me (under jdk1.4, without any jar in endorsed) but fails under 
jdk1.3
Patch committed, thanks for your contribution.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
You are on the CC list for the bug, or are watching someone who is.

Re: undefined page length

[Manuel Mall]

On Tue, 20 Sep 2005 04:33 pm, Luca Furini wrote:
> Andreas L Delmelle wrote:
> > BTW: Is it a correct assessment that implementing this should turn
> > out to be far simpler than fixed page-sizes? IIC, theoretically,
> > the whole page-breaking algorithm can be ignored for indefinite
> > page-heights. getAvailableBPD() would always return, say,
> > Integer.MAX_VALUE?
>
> I don't think the breaking algorithm can be completely ignored, but
> it's a good idea to have getAvailableBPD() return an almost infinite
> value.
>

Wonder if we would run into a limitation here with respect to using int 
and mpt: Maxint = 2147483647mpt ~ 2147483pt ~ 3in ~ 75000cm ~ 2500 
A4 pages vertically. Probably not as this would be all one page kept in 
memory before rendering. An out of memory exception is the more likely 
outcome :-).

> Once the PageBreakingAlgorithm has created the single
> PageBreakPosition, it would be possible to use the stored difference
> in order to set the correct page height (otherwise the page would
> have height =
> Integer.MAX_VALUE even if it contains just a few lines).
>
> Regards
>  Luca
Manuel

Re: undefined page length

[Luca Furini]

Andreas L Delmelle wrote:

BTW: Is it a correct assessment that implementing this should turn out 
to be far simpler than fixed page-sizes? IIC, theoretically, the whole 
page-breaking algorithm can be ignored for indefinite page-heights. 
getAvailableBPD() would always return, say, Integer.MAX_VALUE?


I don't think the breaking algorithm can be completely ignored, but it's a 
good idea to have getAvailableBPD() return an almost infinite value.


Once the PageBreakingAlgorithm has created the single PageBreakPosition, 
it would be possible to use the stored difference in order to set the 
correct page height (otherwise the page would have height = 
Integer.MAX_VALUE even if it contains just a few lines).


Regards
Luca