Handling of text-align="justify" when nesting blocks

[arnd . beissner]

Editors,

please consider the following inconsistency in the recommendation:

Example:


TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
 TEST ENDS A. 

whatever

TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
 TEST ENDS B.


Now what would you expect:

Version A:

TEST TEST TEST TEST
TEST ENDS A.
whatever
TEST TEST TEST TEST
TEST ENDS B.

OR

Version B: (second line is justified)

TEST TEST TEST TEST
TEST   ENDS  A.
whatever
TEST TEST TEST TEST
TEST ENDS B.

Common sense would probably say "A":

But, 7.15.9 of the rec says:

The last (or only) line of any block, and any lines in the block ending in 

U+000A, will be aligned in accordance with the "text-align-last"
property value. If such lines are to be justified specify
"text-align-last='justify'".

In the example, line 2 is neither the last nor the only line of a block, 
and it's also not a line ending in U+000A, so it should be justified.

In contrast to this, 7.15.10 (text-align-last) says
(thanks to Luca Furini for the hint):

"Specifies the alignment of the last line-area child of the last
block-area generated and returned by the formatting object, and to any
line-area generated by the formatting object whose following sibling is a
block-area that is not a line-area, and any lines in the block ending in 
U+000A."

If 7.15.9 were worded like 7.15.10, the example would be formatted like
in Version "A", which is probably what the editors intended.

7.15.9 and 7.15.10 now clearly contradict each other, IMO.
My suggestion is to change the cited portion of 7.15.9 to the
following wording:

"The last line-area child of the last block-area generated and returned
by the formatting object, and any line-area generated by the formatting
object whose following sibling is a block-area that is not a line-area,
and any lines in the block ending in U+000A, will be aligned in accordance
with the "text-align-last" property value. If such lines are to be
justified specify "text-align-last='justify'".

Thanks for considering this,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: Handling of text-align="justify" when nesting blocks

[arnd . beissner]

Luca Furini <[EMAIL PROTECTED]> schrieb am 03.09.2004 10:19:06:

> Section 7.15.10 of the recommendation states that the property
> text-align-last "Specifies the alignment of the last line-area child of 
the
> last block-area generated and returned by the formatting object, *and to 
any
> line-area generated by the formatting object whose following sibling is 
a
> block-area that is not a line-area*, and any lines in the block ending 
in
> U+000A."

Thanks for digging this out. I will make a suggestion to the
xsl-editors to change the wording in 7.15.9 accordingly.

Thanks,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: Handling of text-align="justify" when nesting blocks

[arnd . beissner]

"J.Pietschmann" <[EMAIL PROTECTED]> schrieb am 01.09.2004 22:48:17:

> > 
> > TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE 
LINES 
> >  TEST ENDS A. 
> > 
> ...
> > In the example, line 2 is neither the last nor the only line of a 
block, 
> > and it's also not a line ending in U+000A, so it should be justified.
> 
> It is the last line in the block. Trailing whitespace util the
> closing tag is normalized away (or should be, FOP shows bugs here).
> Why do you think it is otherwise?

Hm, I think it's not the last line of the block. Let's see my example 
again, but this time with ids:


TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
 TEST ENDS A. 

whatever

TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
 TEST ENDS B.


The line 2 ( TEST ENDS A.) is the last line before the block "inner" 
starts, but it's not the last line of the block with id "outer". The last 
line of the block "outer" is: ( TEST ENDS B.).

Get my point, or am I still being unclear?

Can we safely assume the rec. means "block area" here instead of just 
"block"? I think we can't, since then that would mean that the last line 
on a page (or column) would also be formatted left-aligned instad of 
justified even if it's not the last line of the block ("block" as in 
"fo:block").

Thanks for any input,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Handling of text-align="justify" when nesting blocks

[arnd . beissner]

Hi fopdevs,

if you have time, consider this:


TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
 TEST ENDS A. 

whatever

TEST TEST TEST TEST TEST . ENOUGH TEXT TO FORMAT INTO MULTIPLE LINES 
 TEST ENDS B.


Now what would you expect:

A:

TEST TEST TEST TEST
TEST ENDS A.
whatever
TEST TEST TEST TEST
TEST ENDS B.

OR

B: (second line is justified)

TEST TEST TEST TEST
TEST  ENDS A.
whatever
TEST TEST TEST TEST
TEST ENDS B.

Common sense would probably say A:

But, 7.15.9 of the rec says:

The last (or only) line of any block, and any lines in the block ending in 
U+000A, will be aligned
in accordance with the "text-align-last" property value. If such lines are 
to be justified specify
"text-align-last='justify'".

In the example, line 2 is neither the last nor the only line of a block, 
and it's also not a line ending in U+000A, so it should be justified.

Right?

FOP 0.20.5 does A.

Any opinions?

BTW: you can ignore any whitespace/linefeed-treatement issues here (all 
set to default): the above example formats the same with FOP if you put 
all of it in a single line.

Thanks,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: How to tell Driver to open acrobat in a new IE?

[arnd . beissner]

[EMAIL PROTECTED] wrote on 11.08.2004 21:48:24:

> I am parsing my XML file through FOP parser and then telling the driver 
to
> render it as PDF. The process is initiated by clicking on a button on 
IE.
> What happens is the current IE instance opens the acrobat and displays 
the
> PDF it.
> 
> The users have to hit back button to get back to the application.
> 
> My question is how do i tell the Driver to open the PDF in a separate
> instance of acrobat (within a new IE instance) or just by  acrobat
> independently.

First: this is not a question for fop-dev. fop-dev is a mailing list for 
people working on the source code of FOP

Second: you cannot tell the Driver to do that - not because it's not 
implemented, but because it's not possible. You must change your HTML 
and/or JavaScript to tell the browser to open a new window for the link.

Hope this helps,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

RE: SVG Generator

[arnd . beissner]

"Victor Mote" <[EMAIL PROTECTED]> wrote on 12.06.2004 17:35:04:

> It is no longer a concern of mine that FOP has returned to a monolithic
> design, but I think it is a bit unfair to the new developers to imply 
that
> the XSL-FO standard mandates such a design, at least with the reasoning 
that
> has been offered so far.

AFAICS, the cited part of the XSL-FO recommendation only mandates that
for refinement the formatter needs feedback from the area tree in some
situations. It's just a hint to implementors: hey, it's not as simple
as it looks - it's not a pure sequential process. That's it.

Let's also remember that "refinement" and "area tree" are artifacts used 
to
formally describe the *result* of the formatting process. There is no 
reason
to believe there must be a refinement step or even an area tree as such in
an implementation.

Of course, directly following the conceptual procedure outlined in the
recommendation makes it easiest to validate that the implementation is 
"right",
but I don't see that it necessarily leads to the "best" implementation.

Victor's comment 
(http://marc.theaimsgroup.com/?l=fop-dev&m=107074009107318&w=2)
is perfectly valid IMO.

Also IMO, design discussions should be about evaluating opportunities 
in the first place and finding and eliminating showstoppers in the second
place. If the benefits of a certain design are important enough and this
is seen so by several people, the chances are good that the perceived
showstoppers can be eliminated.

I think this also applies to Peter's current suggestions.

My 2 cents,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: Printing to paper edge for a "bleed tab"

[arnd . beissner]

Clay Leeds <[EMAIL PROTECTED]> wrote 28.05.2004 17:57:59:

> The nice thing about this, is that one could set up parameters (stored 
> in config files), to help determine how the output would be rendered. 
> The 'holder' could consult the config file to determine how to proceed.
> 
> Among the items in the config file:
> - minimum margins (t r b l)
> - acceptable fonts
> - font re-mapping?
> - definition of the 'any' font when font not found

> There could also be separate sections based on the renderer, so 
> Postscript output could add job-control/paper-tray selection 
> information as well.

Yes, sure. The only thing I would still want is that you dont't 
*have to* specify all this, and also that it's possible to have
a per-document paramterization for that. Config file only is not
feasible in many environments. I often tend to think of an FO
stream as a "job to process", not a document. A job should be
able to contain everything necessary.

> OT:
> I thought Italy was the place with the largest 'organization' of ideas 
> :-)

Used to be. They outsourced all of that to a company with a CEO named
Berlusconi if I remember correctly. 8-)
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99
Mobile: +49-173-3016917

Re: Printing to paper edge for a "bleed tab"

[arnd . beissner]

"Peter B. West" <[EMAIL PROTECTED]> schrieb am 28.05.2004 17:16:08:

> Thanks Arnd.  My argument is that the renderer must tell the layout 
> engine about font metrics.  I have always regarded PDF and PS (with 
> obligatory fonts) as stable targets in this respect.

They are. PostScript files and PDF should not be created with specifics
of an output device in mind. The only thing that may happen is that
you directly add job-control features to PostScript file - for example
paper try switching. Please be aware that the difficulties I mention are
in the chain Acrobat->printer and PSFile->printer, NOT in the chain
formatter->renderer.

> It's reassuring to find that there are so many ways in which variations
> will creep in to the output of even such a heavily standardised
> format as PDF.  To get the output point-perfect then, the renderer
> needs to know the peculiarities of the output device.

My take on this is - as I hopefully have been able to communicate -
that the renderer should tell the formatter what it *can* do. This
includes but is not restricted to fonts or font metrics. The *holder*
(I deliberately do not say owner here) of this kind of information
should be the formatter (or a separate centralized entity that
the formatter can access). The formatter can also hold information
of its own - like for example a repository of TTF or Type 1 fonts
that all renderers wo are able to handle this type of font can
subsequently make use of. 

Like in a federalistic political system, this structure makes sure
that everyone can give his input into the decision process.
You just have to make sure that there is just *one* entity
responsible for the final decision - otherwise, you're in Germany.. 8-)

More on this later - I still owe Victor an answer.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: Printing to paper edge for a "bleed tab"

[arnd . beissner]

"Peter B. West" <[EMAIL PROTECTED]> wrote on 28.05.2004 01:15:26:

> I suppose that everyone has noticed this exchange on fop-user.
> 
> Peter
> 
> Mike Kellstrand wrote:
> > Mark,
> > 
> > I ran the PDF through Ghostscript and it looks like it is doing the 
trick.
> > I did notice that the same PDF printed in Ghostscript vs. Adobe print 
> > out with slightly different size fonts.Arg!   :)

Is there a specific reason for this pointer?

If there is any doubt: font sizes are the same whereever you print out a 
PDF
- as long as the PDF viewer application and the printer(driver) work 
correctly
and the user hasn't made any mistake.

Possible causes for this kind of problem:

1. The printer (or emulator) does not use exactly the same font, but a 
substitute
with differing metrics. GhostScript default fonts are not perfectly 
compatible
with the metrics of the Adobe base fonts - that goes at least for 
GhostScript
version from about a year ago.

2. This is a variation of 1. Improper setting of font match settings in 
the
printer driver options. Using device fonts in PCL printing is especially
dangerous as many drivers then don't handle Z-order or font color 
correctly in
addition to having device fonts with metrics that match only to 95% or so.

3. The user has made a mistake (page/paper scaling options if the Acrobat 
print
dialog, like fit to page, etc.).

4. The PostScript printer (or emulation) or the printer driver is buggy. 
The
Kyocera PS emulation is a little shaky in my experience - though not 
regarding
font sizes or metrics regarding the base fonts.

We have done lots and lots of PDF and PostScript output for a bunch 
customers
with an output of several 100.000 pages per month (by the way: more than 
50%
of these still done with FOP) and using dozens of different printers, and 
a number of fonts (base fonts as well as others). Any font size or metric
problems during the last years regarding PDFs or PSes could be resolved to 
one
of the 4 reasons - most popular is 3.

Hope this resolves any doubt you might have.

Bye,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: column balancing

[arnd . beissner]

"A.M." <[EMAIL PROTECTED]> wrote 27.05.2004 16:27:29:

> Excuse me for being annoying with the column balancing issue (from 
> fop-user), but it's something that we crucially need. I would like to 
> offer my time to implement this- however it's not clear to me which 
> block attributes are relevant to this. Could someone point me to the 
> page of the spec covering this? (Column balancing is unfortunately the 
> only thing keeping us from FOP.) Thanks.

As far as I can see, column balancing is not really defined as a mechanism
in the XSL recommendation. My interpretation so far is that to do column
balancing if a spanned block follows on the same page and not to do it
if no spanned blocks follows, is one of several allowed user agent
behaviours - and the one that makes the most sense as a default.

If your or someone else finds something in the XSL recommendation
that more precisely defines what should happen, I would be grateful
for a pointer as well.

My 2 cents,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

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: 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: 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: Just do it (was: Re: Borders on Blocks)

[arnd . beissner]

Jeremias Maerki <[EMAIL PROTECTED]> schrieb am 19.05.2004 
20:38:37:

> You guys block yourselves with this strategy and Arnd gets
> even more of a head-start. :-)

8-)
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Re: ANN: FOray

[arnd . beissner]

"Peter B. West" <[EMAIL PROTECTED]> wrote on 19.05.2004 00:12:41:

> I think you are talking about different modularisation contexts here. 
> You might want to clarify this part of the discussion with Victor.

I really thought it was about the "pluggable" layout that Victor brought
up a long time ago. If not, just forget what I said. 8-)

Sorry,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99
Mobile: +49-173-3016917

Re: Incremental vs rewrite

[arnd . beissner]

Clay Leeds <[EMAIL PROTECTED]> schrieb am 19.05.2004 01:03:19:

> It would be interesting to compare some RenderX example output between 
> the two^H^H^H three (ArndFO, fop-0.20.5, fop-1.0Dev)... I suspect there 
> may be other significant differences as well, with performance, heap, 
etc.

Be warned that the RenderX testsuite files require a relatively high 
degree
of spec compliance. Shorthands are used everywhere, all table examples
require auto-layout, and so on. I confess that I learned a few more things
about FO when testing with these files...

> Then again, the more I think about it, the more it seems like Peter's 
> train-of-thought RE: FOP development destabilization. 'We' could be 
> working on FOP development, but instead we're talking about Arnd's (and 
> Victor's) development efforts (I have every reason to believe it is 
> everything he says it is), and discussing how the grass may be greener 
> on the other side of the fence.

That's true. So let's all get back to work. 8-)

>From Peter's mail:
> The thing that immediately strikes me about Arnd's development is that 
> it seems to blow away the theory that incremental modification of an 
> existing code base is always the better way to go.  IIUC, Arnd wrote a 
> formatter from scratch (except for some fo the font handling) in two 
years.

I don't think what I did proves your point. Even though it worked for
me this time, it was a high risk (ok, since I was always prepared to 
treat this a fun project, no risk). It was really a gamble, one I wouldn't
have done under other circumstances - for example not if producing an FO
formatter had been our business then. I suppose when you look around, you
will find much, much more failed "rewrite" projects than failed 
"incremental"
projects. 

In any case, I really don't think you can compare a one-person effort to
that of a distributed group. Also, I believe this is rather a generic
software-development question. If you think you do see the light at the
end of the tunnel for the FOP rewrite then by all means go for it.

There's one thing I want to mention at this point:

The market (make that "community" if you prefer) for FO formatting is
still very small. Growing, but still very small. The more different 
solutions
that we see, the better for the market or community (yes, only to a
certain extent of course). I am sure, even within the open source 
community,
many users would be grateful not to be "locked" into using FOP, but to 
have
an alternative.

My 2 cents, but now finally back to work.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

RE: ANN: FOray

[arnd . beissner]

"Victor Mote" <[EMAIL PROTECTED]> wrote on 18.05.2004 22:12:45:

> The real question on modularity was never whether it should be a 
priority,
> but whether it hurt the project. On open-source projects, priorities are
> really set by each individual. You fix the thing that hurts the most at 
the
> moment, and that might be different for each developer. If I am working 
on
> A, and you are working on B, as long as your work on B isn't bad for the
> project as a whole, I have no right to complain. Nobody has yet put 
forth a
> good argument against modularization, but it was opposed anyway. So now
> we'll have a chance to test it in the real world.

In my formatter, I have implemented modularized layout. From the start, I
was sceptical, and I was indeed tempted several times to throw the concept
out of the window because it got in the way, but in the end it was always
possible to maintain the separation of concerns between different kinds
of layouters (BlockArea, Table, Page, and List for example) even though
the interaction is admittedly complex. And, yes, it's sometimes hard to
follow the logic by staring just at the code - which I prefer to using
debuggers.

To summarize my impressions from this:
1. I would do it again this way.

2. Maintaining clean separation of concerns *forced* me to redesign my
layouter interfaces several times when I added new functionality, but
I gained an implementation that I still understand clearly in its entirety
even I cannot work on it for a week.

3. The only place where I have difficulties after some time off is my
BlockAreaLayouter which is one very large chunk of code. Maybe it's even
worth factoring out a LineAreaLayouter, though I'm not sure of it - the
interaction is really tight.

4. It's too early to estimate how much modularized layout will hurt
performance in the end. My gut feeling is: not much, and it's probably
wort it.

So, from my own experience I can only encourage you to go forward with
your plan. For me, it worked so far. Let's see if the XSL rec turns
up more nasty surprises...

Bye,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

RE: Table processing question - follow-up

[arnd . beissner]

"Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote on 18.05.2004 
18:09:15:

> Indeed, but the columns can be absent in the source FO. In which case
> they're actually to be considered present, and their widths are 
determined
> by the cells in the first row (--or, but I didn't dare consider that
> possibility just yet, in case of auto-layout, by the cell 'in' that 
column
> that has the content with the largest width).

As far as I understand the spec, table-column elements with a column-width
property are mandatory for tables with fixed table layout.

>From the spec: 7.26.9.:
The "column-width" property must be specified for every column, unless
the automatic table layout is used.

To me, this means not only that column-width is mandatory in fixed-layout 
*if*
table-column elements exist, but also that a table-column needs to exist 
for
each column. Since they don't talk about a derived trait, but
of a column-width property that also isn't inherited, I can only conclude 
that
"must be specified for every column" means:

1. In fixed-layout, there MUST be a table-column element for each column.

AND 

2. In fixed-layout, the column-width property must be set in all 
table-column elements.

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99
Mobile: +49-173-3016917

border-collapse WAS: Re: ANN: FOray

[arnd . beissner]

Chris Bowditch <[EMAIL PROTECTED]> wrote on: 18.05.2004 14:31:39:

> What I forgot to say is that I think we should do an initial release of 
FOP 
> after doing just High priority TODO items.

Ok, that changes things, of course.

> Yes, ugly output can be caused without border collapse, but yet 
RenderX's XEP 
> doesnt have border collapse,
> so I dont see an immediate need for it. After all, output only looks 
ugly if 
> you specify borders on every cell edge,
> with careful writing of the FO, the output can still look good without 
border 
> collapse.

True. Well, partially so. If you have, for example, tables with small 
fonts
and lots of narrow columns and horizonal space is scarce, then it gets
increasingly difficult to create good-looking table borders between 
columns
without border-collapse. Maybe my focus is shifted a little too much on 
the
actual problems that I have with my customer's requirements.

Also, in my formatter, I want to implement the collapsing model early, 
because
it's default in FO and because I want to get everything out of the way 
that
I don't have an immediate solution for. Makes me nervous otherwise.

As for FOP, ok, I do agree that getting a formatter out that is at least 
as
good as 0.20.5 may take priority.

Bye,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Tel.: +49-7031-763863-11, Fax: +49-7031-763863-99
Mobile: +49-173-3016917






Chris Bowditch <[EMAIL PROTECTED]> schrieb am 18.05.2004 
14:31:39:

> [EMAIL PROTECTED] wrote:
> 
> > Chris Bowditch <[EMAIL PROTECTED]> wrote on 18.05.2004 
12:03:33:
> > 
> >>This is very true, I also have the same concerns, which is why I have 
> >>set out 
> >>some simple objectives that must be met before the redesign is ready 
for 
> >> an initial release. See here:
> >>
> >>http://xml.apache.org/fop/design/layout.html#status-todo
> > 
> > One comment on the todos:
> > 
> > - border-collapse is both important and difficult. I am still fiddling 

> > with
> > details of the spec. I suggest ugrading the priority. Not supporting
> > border-collapes yields ugly output.
> 
> What I forgot to say is that I think we should do an initial release of 
FOP 
> after doing just High priority TODO items.
> Yes, ugly output can be caused without border collapse, but yet 
RenderX's XEP 
> doesnt have border collapse,
> so I dont see an immediate need for it. After all, output only looks 
ugly if 
> you specify borders on every cell edge,
> with careful writing of the FO, the output can still look good without 
border 
> collapse.
> 
> > Well, unfortunately not so much spare time, but as I said, doing it
> > alone really, really helps. And I very much tried to aggregate as
> > much spare time as possible into full dev-only days. That helps, too.
> > With the same background, most of you committers could have done the
> > same. If you look at it, most successful projects initially had
> > 1 or 2 people at the start who did the core work, and then others
> > joined to make it complete. If I had joined the redesign team, FOP
> > wouldn't be much farther than it is now, because most of my time
> > would have gone to discussions, which in turn would also have taken
> > up other committer's time.
> 
> Perhaps, but perhaps not. As long as you dont make major changes, then 
its 
> possible to proceed without seeking group consent on every little item. 
Thats 
> what I'm trying to do. Work towards a working layout a bit at a 
timeusing the 
> existing redesigned framework.
> 
> > What I *can* offer to contribute is discussion about the FO spec or 
about
> > implementing PS oder PDF output. This is a concern that we probably 
share
> > and that needs discussion in any case. However, for actual 
implementation
> > discussions I feel a little reluctant. If my pet project becomes a 
product
> > in the future, we will have the same issues coming up here that we had 

> > with
> > the RenderX guy speaking up here recently. This is not what I want - 
> > though
> > I think what he did was perfectly ok, well-meaning and to be 
applauded. If
> > I recall correctly, the uproar was resolved, the RenderX guy got his 
> > deserved
> > apology, but the consensus was that the FOP code should be kept 
"clean" 
> > from
> > competitor's code or even ideas. If I remember that correctly and this 

> > still
> > stands, then I would rather not discuss algorithms here.
> 
> Fair enough. That was an unfortunate affair, and one I'm keen not to 
repeat.
> 
> Chris
> 
> 

Re: ANN: FOray

[arnd . beissner]

Chris Bowditch <[EMAIL PROTECTED]> wrote on 18.05.2004 12:03:33:

> This is very true, I also have the same concerns, which is why I have 
set out 
> some simple objectives that must be met before the redesign is ready for 
an 
> initial release. See here:
> 
> http://xml.apache.org/fop/design/layout.html#status-todo

One comment on the todos:

- border-collapse is both important and difficult. I am still fiddling 
with
details of the spec. I suggest ugrading the priority. Not supporting
border-collapes yields ugly output.

> We have in fact completed the first item. Once we have completed the 
other 
> tasks the redesign wont be far behind 0.20.5. Once we do a release, I 
believe 
> the project will gain some momentum.

That I agree with. May I was too pessimistic regarding the progress.
 
> I'm impressed. You must have a lot of spare time, and be a very talented 

> programmer. I would be grateful if you could help with any of the 
> tasks listed 
> above, so we can get a release of the redesign and overcome FOP's 
> current dilema.

Well, unfortunately not so much spare time, but as I said, doing it
alone really, really helps. And I very much tried to aggregate as
much spare time as possible into full dev-only days. That helps, too.
With the same background, most of you committers could have done the
same. If you look at it, most successful projects initially had
1 or 2 people at the start who did the core work, and then others
joined to make it complete. If I had joined the redesign team, FOP
wouldn't be much farther than it is now, because most of my time
would have gone to discussions, which in turn would also have taken
up other committer's time.

What I *can* offer to contribute is discussion about the FO spec or about
implementing PS oder PDF output. This is a concern that we probably share
and that needs discussion in any case. However, for actual implementation
discussions I feel a little reluctant. If my pet project becomes a product
in the future, we will have the same issues coming up here that we had 
with
the RenderX guy speaking up here recently. This is not what I want - 
though
I think what he did was perfectly ok, well-meaning and to be applauded. If
I recall correctly, the uproar was resolved, the RenderX guy got his 
deserved
apology, but the consensus was that the FOP code should be kept "clean" 
from
competitor's code or even ideas. If I remember that correctly and this 
still
stands, then I would rather not discuss algorithms here.

Have a nice day out there,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Antwort: Re: ANN: FOray

[arnd . beissner]

"Peter B. West" <[EMAIL PROTECTED]> schrieb am 18.05.2004 11:57:38:

> I am awe-struck that you have achieved so much in that period.  How much 

> of the Rec have you implemented?

Peter, it really helps if you have a strong background on PostScript, PDF
and fonts as well as text formatting. Also, I can be very efficient if I
can do it alone or if I can decide how it's done, but I don't have the
patience or talent for discussing technical concepts in writing. Why
write when you can code? Yes, I know, this is a personal deficiency, but
it seems like I'm stuck with it.

Also, we shall have to see how great everything is when it's done. I won't
judge right now. It feels right, but I will only be sure of it when it's 
done.
Besides performance issues, I still find new things/aspects in the
recommendation that I didn't notice or understand so far. I have to 
confess
that understanding the XSL-FO recommendation has been my greatest 
intellectual
challenge in this project so far...

Some sketches of what my formatter does/is capable of now:

Architecture:
- can do single-pass or multi-pass processing or selective multi-pass
- uses push-processing with pull-processing in some places
- *designed* to handle all requirements of the rec.
- designed to be able to provide good error handling (worded this way,
because right now, it sucks, like in FOP...)

Rec aspects:
- basic formatting stuff works
- property handling works
- shorthand properties work
- expression parser works
- table formatting works but still sucks regarding border handling
- references, links fully work
- keeps and breaks work, but no resolution algorithm so far
- bookmark stuff from XSL 1.1 draft
- footnotes work
- No floats so far
- only rudimentary image support (only PNG so far)
- inline formatting is pretty rudimentary right now.
- no automatic hyphentation
- only default orientation and writing modes

Most of these aspects, though, have an attribute here and there that's
not yet implemented or not completely implemented. I have focused on 
things
that I either need for our customers, or that I wanted to do early to
validate the design. So right now I can do most difficult things but not
many of the simple things. For example, I could do page-number-citations
before I could do more than 1 font. 8-)

To make all of this really, really work for users, a lot of testing and
tedious coding needs to be done. We will have to sort that out now.

By the way: the RenderX test suite documents are a very good starting 
point
to find out how much of the spec a formatter can handle. They really do
nasty things (this is absolutely meant as a compliment).


Bye,

Arnd
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH






"Peter B. West" <[EMAIL PROTECTED]> schrieb am 18.05.2004 11:57:38:

> Arnd,
> 
> I am awe-struck that you have achieved so much in that period.  How much 

> of the Rec have you implemented?
> 
> Peter
> 
> [EMAIL PROTECTED] wrote:
> > 
> > So what happened was: I now have an XSL formatter that is in my 
estimation 
> > further
> > along than the FOP redesign and that does most things that 0.20.5 does 
and 
> > a lot of
> > things that 0.20.5 does not. I confess that so far, I did borrow the 
> > TrueType font
> > reader from FOP. What am I going to do with it? Well, it's not really 
> > decided yet.
> > The most likely scenario is to make it a commercial product. BTW: why 
was 
> > I fast?
> > I'm good (like you), I had experience in many of the areas involved, 
and - 
> > very
> > important - I didn't need to discuss my architectural decisions 
because I 
> > did it
> > alone. I had fun.
> 
> -- 
> Peter B. West 

Re: ANN: FOray

[arnd . beissner]

trong developer WITH 
enough
time on the horizon), I believe Model B is what would work best. Your 
existing
development model for FOP 1.0 is taking too long IMO. This is not a 
criticism
of any of you, but a personal assessment of what I think can be achieved 
with
the time available to you. It's also still more a gut feeling that an 
analysis.
If you can draft a realistic project plan with people assigned and that 
gives a
reasonable estimate on when you will be done, you can probably do it.
If you can't or the result is too disappointing, please reconsider 
refactoring
the maintenance branch.

What Victor did was going to happen some day or other. Like me, probably a
number of others have their own local 0.20.5 branch with some enhancements
(yes, for some customers I still use my hacked-up version of 0.20.5).
I think his project is good for FOP as long as both projects manage to 
share
at least some things.

Like two years ago, I still don't feel all that comfortable about speaking
up on this. After all, it's *your* project, and what the f*** do I have to
say about it. Ok, this time I decided to do it. Please don't be offended
- it's really meant as a personal opinion from an interested bystander.
I hope you can accept it as such.

Thanks for listening,

Arnd Beissner
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH

Antwort: Web Start

[arnd . beissner]

Hi Peter, 

we use Web Start in a customer project.
It's a good solution to deploy Java applications as a JAR file, even with
native code and such.

Some caveats:
-The security manager can get in your
way if you want things like filesystem access. You have to sign your jar
and each user has to accept your signature once per application.
- You cannot catch uncaught exceptions
in JNLP applications. This is useful for GUI applications, so you can catch
and for example log these exceptions. With JNLP, AWT/Swing creates its
own thread group so you're out of luck there. Maybe not an issue for fop.
- Only comes with JRE 1.4 by default,
and older WebStart version are quite buggy in my experience.

So far I cannot see how exactly WebStart
would be useful for FOP regarding licensing stuff, because your "sources"
for parts like hyphenation libs still need to be JNLP jars, so you still
need someone to actually provide these jars and thus take responsibility
regarding legal issues. As for as I see it, you don't gain anything.

But if you have something more concrete
in mind, please feel free ask more concrete WebStart questions.

Hope this helps,
-- 
Arnd Beißner
Cappelino Informationstechnologie GmbH


"Peter B. West" <[EMAIL PROTECTED]>
schrieb am 18.03.2004 15:40:19:

> Fops,
> 
> Does anyone have any detailed knowledge of Web Start?  It occurred
to me 
> that it may be a way to resolve some of the licensing issues we (and

> other projects) are running into.  Any educated thoughts on the
matter?
> 
> Peter
> -- 
> Peter B. West 
> 

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

[arnd . beissner]

Nicola Ken Barozzi wrote:
> > IF the integration FOP-iText is done in a way where PDF
> > output via iText is not just an option but a replacement
> > for the existing PDF output - or even for the other renderers,
> > too, then I'd say this step contradicts the intention
> > though not the letters of the Apache license.
>
> This is a strong opinoin. Remember that the Apache license is a *license*,
> not the community. Apache values the community, and the license is there to
> help the community.

Yes, I agree to all of this (including the "strong opinion"). Still, I think
you underrate the importance of the license. In marketing terms: what is it
that makes Apache and GNU a "brand", while SourceFourge is not widely seen
as a brand. I think it's the license.

If I take something from the Apache projects, I know - because of the Apache
license - that I can do most everything with it as long as I mention the
origin in an appropriate way. This makes its very simple to use Apache
projects in commercial projects in medium-size and large companies. Basically
it boils down to this: If I want to use open-source components in a customer
project, I can use Apache-licensed stuff with no problems. MPL, LGPL and GPL
licensed components give me so many headaches when used in commercial customer
projects that I no longer even try to use them (with the exception of
internal-use-only projects). I just want to design and implement software, not
fuss with legal departments, you know... 8-)

Warning: Strong opinion follows
The Apache project just would not be the same if it adopted the MPL, LGPL or GPL.
Also, a number of contributors would quit in that case. If this is true, the
Apache license is still a *license* but not *only a license*. In a sense, the
license defines what persons the community consists of.

FULL STOP

Philosopical issues aside, if the integration/collaboration is planned as you
say, then most points of my original mail become moot. Remember, my mail started
with an uppercase IF. The discussion here on fop-dev showed that it was NOT
clear that PDF via iText would only be an option, not a replacement.

And one more thing - I recite your citation:
"
The goals of the Apache XML FOP Project are to deliver an XSL FO->PDF
formatter that is compliant to at least the Basic conformance level
described in the W3C Recommendation from 15 October 2001, and that complies
with the 11 March 1999 Portable Document Format Specification (Version 1.3)
from Adobe Systems.
"

From this, it's clear that as soon as FOP no longer outputs PDF by itself, but
using a non-Apache-licensed component, then it not longer fulfills the original
goal. This may be good: it makes a lot of sense to separate formatter
and renderer if the abstraction layer is done well (this won't be an easy task,
I'm pretty sure of that).

Technically, it's very tempting to do what you propose. In fact, technically,
I'm all for it. Let's just be aware that the license problem is not only a
philosophical issue.

There is a real reason why there are different types of licenses.

And as for this:

> > This would reduce the usefulness of
> > FOP for a (unknown, agreed) number of users while
> > enhancing the usefulness for others
> > (not license-concerned users).

> I fail to see how this reduces usefulness.

If n persons are using FOP now and some of these can no longer
use FOP because a part of FOP they need has a license they can't use, then
I'd say this reduces FOPs usefulness for these "some" persons, despite being
more useful to others.

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

Re: [PROPOSAL] FOP+iText = FOP-NG -next generation- (was: merging twolibraries)

[arnd . beissner]

Nicola Ken Barozzi wrote:
> Given the licences, nobody is prohibited to cross-collaborate. iText
> developers can send patches to FOP and viceversa, and be [VOTE]d as usual
> when the time is right.
> FOP can distribute iText jar as it's MPL, and both projects would cross-link
> in a clear way.

Advance warning: I didn't follow possible discussions on the iText list regarding this issue.

IF the integration FOP-iText is done in a way where PDF output via iText is not just an option but a replacement
for the existing PDF output - or even for the other renderers, too, then I'd say this step contradicts the intention
though not the letters of the Apache license.

Why? If FOP - under Apache license - can no longer be used for essential purposes without using an additional
component (iText) under MPL or LGPL, then in effect FOP is no longer Apache licensed, though technically
speaking it still is. This would reduce the usefulness of FOP for a (unknown, agreed) number of users while
enhancing the usefulness for others (not license-concerned users).

My personal favourite would be a FOP renderer implementation that makes use of iText. Then, time could
tell whether there are enough people interested in keeping Apache-licensed PDF output alive.

If the decision goes toward a full replacement, I'd say that at least all existing FOP committers and possibly
the major contributors to FOP should agree to this step as it - in one respect - decreases the value of their work so far.

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

Re: Using Avalon/Logkit

[arnd . beissner]

Joe Batt wrote:

> Given the above is true, you could use something as simple as printlns 
> to s global print writer.  In debug mode it would go to the bit bucket. 
> OK, I've used log4j, so I understand you may want something a little 
> more substantial than that, but why does the user care to integrate FOP 
> debugging into a larger logging structure?

I agree with all of your other points - I think you state the purpose
of logging very clearly. However, for this point, my answer
is: yes, the user does care, because:

1. If a solution is deployed at a user's site and the user observes problems,
   he or she wants to be able to reproduce the problems with logging turned
   on, because then the log file can be sent to the creator of the solution,
   whether that's a company or an open source initiative.

2. If a solution consists of multiple building blocks like FOP, and the
   user wants to turn on logging for the reason outlined under 1., then
   it's preferable that all building blocks share the same logging mechanism.

Nevertheless, I have another point about user-side logging that matches your
points nicely:

However much I like logging (I actually prefer logging and staring into
source code over using debuggers), I have one general problem with logging
in the "production code". Quite a number of developers seem to misunderstand
logging as a replacement for careful and thorough error handling and recovery.
In my opinion, logging (in production code) is always only a diagnostic
enhancement of error handling - not a replacement.

BTW: Yes, I do prefer log output over no error handling at all. 8-)

Arnd Beissner
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

Re: pb with jpegs

[arnd . beissner]

Cerious Software (www.cerious.com) has a (Windows) product called ThumbsPlus (about $150 or so),
which includes batch transformations - I have used it to do batch color transformations, but of
course it also does simple load-save-transformations.

I don't know whether FOP/Jimi handles JPEGs saved by this product - but I think they
have a time-limited trial version for download.

Hope this helps,
--
Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

Re: FOP: Font problems

[Arnd Beissner]

Rachael Blank wrote:
> I have also tried font-family="serif"
>  
> In both cases, the text displays correctly (Times Roman 
> 12pt) on many 
> computers at my work site and some at remote sites.
>  
> BUT...There is one client location that displays this 
> same pdf in 10pt Times 

My guess is that there's a problem with the installed fonts on that
specific machine. When I encounter font problems in PDF documents, the
first thing I do is check the document properties in the PDF reader
application. The fonts dialog box (don't know exactly how it´s labeled
in the english version) shows the font names as contained in the PDF 
and 
the actual font selected by the PDF viewer.

Hope this helps,

Arnd Beissner
--
Arnd Beissner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917

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

Re: Exceptions while running embedde fop multithreaded

[Arnd . Beissner]

> Running several threads calling
> org.apache.fop.apps.Driver.run(Driver.java:508) causes nullpointer
> exceptions.
>
> Is FOP meant to support asynchronous calls and have I found a bug, or is it
> not thread safe ?

When I last browsed in the source code (0.20.2 I think), I had the impression
that FOP (at least when seen as a whole) was not explicitely designed to be thread-safe.

The class Configuration keeps its data in static Hashtables, so you will at least
share the FOP configuration between threads. This may (or may not) be the only thing.

I stumpled upon this while figuring out how to run fop repeatedly without restarting
a VM each time.

Hope this helps,

Arnd Beissner

Arnd Beißner IT-Engineering
Bahnhofstr. 3, 71063 Sindelfingen, Germany
Email: [EMAIL PROTECTED]
Phone: +49-7031-463458
Mobile: +49-173-3016917