Got Plass' dissertation

2005-03-10 Thread Jeremias Maerki
I got my copy of Michael Plass' dissertation today. A cursory overview
shows that this document will provide some insight on using Knuth
element model for page breaking but it also makes clear that we still
have to come up with solutions for certain tricky problems that he
didn't have to deal with back then. At any rate, the dissertation seems
more helpful than the two documents we found by Brüggemann-Klein, Klein
and Wohlfeil.

Jeremias Maerki



Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-10 Thread Jeremias Maerki
That's all correct although the third point does not really have
anything to do with the bitmap renderer.

On 10.03.2005 14:34:57 Renaud Richardet wrote:
 Let me sum up this tread to see if I get the picture:
 
 * Sun's codec [1] will not be integrated.
 * instead, Batik's transcoders will be used [2].
 * where and how these transcoders will be made available to fop will
 be discussed next week [3]
 * I'll start by implementing basic functionalities for TIFF and PNG
 using Batik's codecs. This will be 1.3 compilant. I should be able to
 use the actual codecs without modifications.
 * aditional functionalities (like TIFF compressions) will be added via
 the Java Image I/O (needs Java 1.4) or via JAI.Those additional
 functionalities will be stored in a separate directory (src/java-1.4).
 * an alternative would be to create|integrate these functionalities in
 the Batik code.
 * I should check that the output isn't restricted to 72-dpi [4]
 
 Any input to tell me if these assertions are true is welcome.
 
 Regards,
 Renaud
 
 [1] http://java.sun.com/developer/sampsource/jai/
 [2] 
 http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/
 [3] 
 http://mail-archives.eu.apache.org/mod_mbox/xmlgraphics-general/200503.mbox/[EMAIL
  PROTECTED]
 [4] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10756



Jeremias Maerki



OpenOffice hyphenation in Java - YESSSSSS

2005-03-10 Thread Jeremias Maerki
Look what I've just found:

http://linux.org.mt/projects/jtextcheck/jtextcheck-ooohyph-plugin/index.html

It's LGPL (and so are OO's hyphenation patterns if I remember correctly)
but if we provide a plug-in mechanism and host the actual adapter under
the LGPL at http://offo.sourceforge.net/ we could provide the same
hyphenation functionality as OO.

Info on LGPL use by Apache software:
http://wiki.apache.org/jakarta/Using_20LGPL_27d_20code
http://wiki.apache.org/jakarta/LicenceIssues

Now, can we please get rid of all hyphenation patterns in FOP? Please,
please. Just joking, but I'd feel better.

Jeremias Maerki



Re: Got Plass' dissertation

2005-03-10 Thread Jeremias Maerki

On 10.03.2005 16:15:10 Victor Mote wrote:
 Jeremias Maerki wrote:
 
  I got my copy of Michael Plass' dissertation today. A cursory 
  overview shows that this document will provide some insight 
  on using Knuth element model for page breaking but it also 
  makes clear that we still have to come up with solutions for 
  certain tricky problems that he didn't have to deal with back 
  then. At any rate, the dissertation seems more helpful than 
  the two documents we found by Brüggemann-Klein, Klein and Wohlfeil.
 
 Hi Jeremias:
 
 I got my copy yesterday and spent some time in it as well. I wanted to weave
 some thoughts about it into the thread from a few days ago that dealt with
 this same topic. In that thread, you raised the same two issues that I have
 been troubled about for page-breaking: 1) differing page IPDs, and 2)
 side-floats.
 
 WRT differing page IPDs, I think it is probably very acceptable in almost
 every case to simply change the rules. IOW, If you want to use layout
 strategy X, you must do so on a page-sequence-master that has all page IPDs
 the same and that uses the same column-count. (Plass acknowledges that the
 problem to be solved is two-dimensional, but specifically says that his
 algorithm is one-dimensional.) Whether dealing with business forms
 (invoices, purchase orders, etc.) or high-end book publishing (I have
 experience with both), I cannot think of a use case for differing IPDs on
 pages in the same page-sequence. If the goal is 100% standard compliance,
 this isn't good enough. However, if the goal is to get some work done for a
 client, and it doesn't hinder future 100% compliance, then this would be the
 way I would address it.

A fact is that FOP 0.20.5 had no problems with differing available IPDs.
With Luca's suggestions I think we can (auto-)configure the page
breaking algorithm (read: no separate layout strategy) so it can handle
differing IPDs.

 Side-floats are another story. Plass addresses them by adding a new
 primitive to the box/glue/penalty model, called insert (page 15). However,
 I thought the following was pretty interesting as well, drawn from the last
 paragraph of his dissertation:
 
 There are other ways of incorporating approximations into the pagination
 routine; for instance, inset figures could be handled satisfactorily by
 doing the pagination as if they were full width figures with the same area
 as the original figures; afterwards the paragraphs could be re-broken in
 order to fit them around the figures. The optimizing line breaking algorithm
 would be helpful in this regard, since it could break the text on the page
 in such a way that it would come out to the right number of lines. Layout
 artists traditionally use approximate copyfitting techniques to do such
 tasks, so methods like this hold much promise.
 
 So, if an insert requiring 4 square inches is required, and the IPD is six
 inches, add 2/3 of an inch to the BPD of the block, do your copyfitting,
 then come back and lay the block out properly later.
 
 After thinking through all of these papers and ideas, I am more convinced
 than ever of the utility of pluggable layout. But I guess you guys like
 branches better :-)


Jeremias Maerki



Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Jeremias Maerki
That's no problem, I think, because Batik has a TIFF encoder [3] already
in their codebase and we can move this code to the common area and use
that. Shouldn't be difficult to adjust.

Otherwise, I'd rather use ImageIO even if it's only available in JDKs
=1.4.

[3] 
http://cvs.apache.org/viewcvs.cgi/xml-batik/sources/org/apache/batik/ext/awt/image/codec/tiff/

On 09.03.2005 11:30:51 Oleg Tkachenko wrote:
 Jeremias Maerki wrote:
 
  Thanks to Glen for raising the issue. The ideal approach is if Oleg
  would pack up his TIFFRenderer and donate it to the ASF accompanied with
  a software grant [1], but Oleg is a FOP committer and has a CLA on file.
  So if Oleg attaches a ZIP with the sources for the TIFFRenderer (ALv2
  already applied) to a Bugzilla entry along with a note that we may
  include it in FOP, that's good enough for me. It's not that the thing is
  a big application in itself even though some people would argue works
  like Renaud's AWT patch and Oleg's TIFFRenderer must go/run through the
  Incubator.
 
 To make things even more complicated, TIFFRenderer is just a thin 
 wrapper around some weird licensed [1] Sun's codec sources, called Java 
 Advanced Imaging API 1.1.1 Sample Source [2], which includes some 
 provisional bits of JAI. I'm not sure if we want to use it. What about 
 using full-blown JAI?
 
 [1] 
 http://www.tkachenko.com/fop/JAI_1.1.1_sample_io_sourcecodelic.10_23_01.txt
 [2] http://java.sun.com/developer/sampsource/jai/
 -- 
 Oleg Tkachenko
 http://blog.tkachenko.com
 Multiconn Technologies, Israel



Jeremias Maerki



Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Jeremias Maerki
No, definitely not. From what I learned from you, that's what you intend
to do. FOP pursues a different strategy. I believe that you can't get
the same quality PDF with all cool features with a PDF renderer that
operates with a Java2DRenderer as its base.

On 09.03.2005 12:34:20 Peter B. West wrote:
 That will be extremely useful.  However, I was trying to clarify the 
 situation of PDFRenderer.  The impression I got from Renaud's comment 
 was that the Java2DRenderer was to be the basis of all renderers.  Hence 
 my interest.



Jeremias Maerki



Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Jeremias Maerki

On 09.03.2005 12:51:11 Renaud Richardet wrote:
 I downloaded sun's codecs [2] that Oleg used in his TIFFRenderer.
 Jeremias, you mean that we can legally just put those in the FOP-code?

This would have to be checked out. I'd rather not, especially when we
have PNG and TIFF codecs under Apache license already available.

 Following codecs are included in [2]:
 - TIFF
 - JPEG
 - PNG
 - BMP
 So it should be possible to create a renderer for each of this file
 formats. But do we need them all?
 Do we also need GIF encoding ([2] only supports GIF decoding) . If
 yes, we'll have to use other libraries like ACME Labs GIF encoder
 (right?)

I would like to suggest that you implement TIFF and PNG output using
Batik's codecs.

 Besides, I haven't understand yet if Oleg will donate his code to Apache.

I have the impression that he wants to. There are simply a few issues to
look at. Looking at possible licensing issue I'd suggest Oleg simply
donates his own classes (not the codec) to the FOP project by applying
the Apache license and posting them as a Bugzilla issue. You can then
use these classes to implement output via Batik's codecs. Or you simply
reimplement the same functionality without copy/paste. :-) As he said,
it's only a thin wrapper. The key is to have codecs with the right
licensing.

  Otherwise, I'd rather use ImageIO even if it's only available in JDKs
  =1.4.
 I thought FOP should be 1.3 compilant [3]? So how do we go around that?

That's right. But nothing stops us from providing additional code that's
JDK 1.4 dependent as long as it's not core functionality and it's in a
separate directory (src/java-1.4).

 Regards,
 Renaud
 
 [3] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=1332332



Jeremias Maerki



Re: Skype-conference on page-breaking?

2005-03-09 Thread Jeremias Maerki
Sounds to me like 2) is the way to go right now. This would mean minimal
recreation of vertical boxes in case of changing available IPD. Sure,
this is an exotic case but XSL-FO makes it possible, therefore we must
be prepared for it.

Thanks for the hints and the helpful example.

On 08.03.2005 19:43:57 Luca Furini wrote:
 Jeremias Maerki wrote:
 
  Luca, do you think your total-fit approach may be written in a way to
  handle changing available IPDs and that look-ahead can be disabled to
  improve processing speed at the cost of optimal break decisions?
 
 I think that a first fit algorithm could be implemented in two different ways:
 1) wait until the list of elements representing a whole page-sequence is
collected, and call findBreakingPoints(); this method will call a
different considerLegalBreak() method, much simpler and faster than
the knuth's one.
 2) start building pages little by little: the FlowLM returns elements to
the PageLM as soon as one of its own child returns them
 
 Alternative 1) is much like the total fit algorithm: breaks are computed
 at the end of each page-sequence; even if the evaluation method is much
 faster than Knuth's one, there could still be a long wait in order to get
 the whole list.
 
 With alternative 2) the PageLM would behave much the same as it now does:
 as soon as a page is filled, it is possible to call addAreas. Note that
 the last elements in the partial sequence cannot be considered as feasible
 break. For example, if there is a block which creates 6 lines, the
 sequence will be something like:
  box
  box
  penalty(not infinite)
  box
  penalty(not infinite)
  box
  box
 and the evaluation must stop at the second penalty; only when some
 following elements are known it will be possible to decide whether the
 last two lines could be at the end of a page.
 
 If the IPD is always the same, I think the two alternatives are
 equivalent, and the first one is better because it just needs a
 different considerLegalBreak() method; as the output file cannot be
 printed until the end of the process, the only advantage of 2) could be
 memory usage.
 
  That's the part where I have a big question mark about changing
  available IPD. We may have to have a check that figures out if the
  available IPD changes within a page-sequence by inspecting the
  page-masters. That would allow us to switch automatically between
  total-fit and best-fit or maybe even first-fit.
 
 If the IPD changes, I fear 2) must be necessarily used: if a block is
 split between pages with different ipd, only a few lines need to be
 recreated.
 Using 1), the LineLM should know how wide the lines are, but this cannot
 be known as page breaking has not yet started.
 
 The check could be done before starting the layout phase: if there is a
 change, 2) is used, otherwise 1).
 Maybe, the check could be even more sophisticated: for example, if the
 first page is different, but the following are equally wide, we could use
 2) to create the first page and then switch to 1).
 
  A remaining question
  mark is with side-floats as they influence the available IPD on a
  line-to-line basis.
 
 This is a question mark for me too! :-)
 
  One thing for a deluxe strategy for book-style
  documents is certainly alignment of lines between facing pages. But
  that's something that's not important at the moment.
 
 I have created and implemented a new property right about this! :-)
 
  I'd be very interested to hear what you think about the difficulty of
  changing available IPD. The more I think about it, however, the more I
  think the total-fit model gets too complicated for what we/I need right
  now. But I'm unsure here.
 
 If changing ipd is really important and not just a theorical possibility,
 we could start implementing 2, and later add the check and the algorithm
 1: the getNextKnuthElements() in the block-level LM could be used in both
 cases.
 
 Regards
 Luca
 
 



Jeremias Maerki



Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Jeremias Maerki
Yes, please, because it's a lot easier to handle inside an IDE. You
simply define an additional source folder if you're on JDK 1.4, and you
don't get compile error on JDK 1.3.

On 09.03.2005 16:34:39 Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
  
Otherwise, I'd rather use ImageIO even if it's
  only available in JDKs
=1.4.
   I thought FOP should be 1.3 compilant [3]? So how
  do we go around that?
  
  That's right. But nothing stops us from providing
  additional code that's
  JDK 1.4 dependent as long as it's not core
  functionality and it's in a
  separate directory (src/java-1.4).
  
 
 BTW, does it have to be in a separate directory?  Can
 we keep it in the directory it would otherwise be in
 if FOP were 1.4-based but somehow alter the Ant
 scripts to help the 1.3-only users?
 
 Glen



Jeremias Maerki



Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-09 Thread Jeremias Maerki
Ah, there's the catch. Yes, CCITT4 is particularly interesting which is
not supported by the code in Batik. But still, I think we don't have to
support everything under JDK 1.3. I wonder how many people under JDK 1.3
would need that particular compression type. And if they really do they
then have several examples on how to adjust the bitmap renderer for
themselves. And a additional JAI implementation is certainly not a big
deal after we have the first one.

On 09.03.2005 16:38:33 Oleg Tkachenko wrote:
 Jeremias Maerki wrote:
 
  That's no problem, I think, because Batik has a TIFF encoder [3] already
  in their codebase and we can move this code to the common area and use
  that. Shouldn't be difficult to adjust.
 
 Last time I checked Batik's TIFF encoder was kinda limited WRT some TIFF 
 compressions, and that's the reason I used the codec from Sun. That 
 would be really nice to fix Batik's codec instead.


Jeremias Maerki



Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-03-08 Thread Jeremias Maerki

On 08.03.2005 03:18:21 Renaud Richardet wrote:
snip/
 On Mon, 28 Feb 2005 , Jeremias Maerki wrote:
 
   AbstractRenderer: I moved what I could reuse from PDFRenderer to
   AbstractRenderer: renderTextDecorations(), handleRegionTraits(), and 
   added the
   needed empty methods.
  
  I think that was good although only time will tell if this will hold for
  all renderers to come. 
 
 Eventually, I didn't modify AbstractRenderer, PDFRenderer and PS
 Renderer at all.
 The implementation of AWTRenderer is close to the other renderers, so
 that putting some methods in AbstractRenderer should not be a big
 problem.

I agree.

   Speaking of startVParea(), could we rename it to something more 
   meanigfull?
   Proposition: TransformPosition, or something like this.
  
  Actually, I like startVParea() (or rather startViewportArea like I would
  rather call it) because only for viewport a new transformation matrix is
  necessary. 
 
 startViewportArea() is fine for me.
 
  I think the Java2D approach is not unlike the
  PDF/PS approach. 
 
 Adobe was Sun's closest partner when they developed the Java2D API.
 
   I implemented a simple .bmp rendering (BMPReader.java). 
   If there's a better way to render .bmp (JAI?), let me know. 
  
  This should not be necessary. We have a BMP implementation in 
  org.apache.fop.images.
  The BMP bitmaps should be loaded through that mechanism. 
 
 OK, now I see. But how can I get an awt.Image from a FopImage?

I've modified your patch to demonstrate, but it needs some additional
work to handle the different color models. Probably the image package
should be extended to provide the necessary information/methods.

  BTW, Using Graphics.create() you should be able to create a copy of the
  current Graphics2D object. By pushing the old one on a stack and
  overwriting the graphics member variable should should be able to create
  the same effect as with currentState.push()/saveGraphicsState() in
  PDFRenderer.startVParea () and currentState.pop()/restoreGraphicsState
  ()in endVParea(). When leaving a VP area you can simply restore an older
  Graphics2D object for the stack and continue painting. This will undo
  any transformations and state change done in the copy used within the VP
  area. See second paragraph in javadocs of java.awt.Graphics.
 
 Thanks for the hint. I did just that in AWTGraphicsState (same as
 PDFState). It holds all the context (font, colour, stroke,
 transformation) of the current graphics, and can act as a stack, too.
 I created an interface (RendererState) that could be implemented by
 all xxxState of the renderers. To be discussed...

I moved the interface into the awt package for now since it contains
Java2D-dependant methods and classes. I don't see right now how the
other renderer would fit into the picture. The PDF renderer's state
class is in the pdf package and should probably stay there.

 I also added a Debug button on the AWTRenderer-Windows, which
 outlines the blocks. This is just a test, and I would like to develop
 a full-fledged visual debugger [1].

That's an interesting feature.

 If this code works for you, then I'll start to separate the
 Java2DRenderer and the AWTRenderer. Otherwise, please tell me how I
 can improve my code.

I liked the patch. It's a big step forward. Keep it up!

 Renaud
 
 [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D



Jeremias Maerki



Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-03-08 Thread Jeremias Maerki
By the way, Renaud, you should sign and send an ICLA (Individual
Contributor license agreement) to the ASF if you haven't done so already.

http://www.apache.org/licenses/#clas

Just so we're on the safe side. After all you're not just doing little
bug fixes. Thanks!

Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/render/awt/viewer PreviewDialog.java

2005-03-08 Thread Jeremias Maerki
No. It's quite ok like this. It is in line with my vision how renderers
should be made available to FOP in the future (dynamic registration like
the FOP extensions). It's clear that the AWT preview doesn't manifest a
certain type of file that has an officially defined MIME type. But
nobody is blocked from creating a new, special one for special purposes.
Only if you want to be purist about MIME types is this probably
suboptimal. The MIME type is ideal for choosing a renderer. JPS, for
example, works much in the same way.

RFC 2045 [1] says this:
 (1)   Private values (starting with X-) may be defined
   bilaterally between two cooperating agents without
   outside registration or standardization. Such values
   cannot be registered or standardized.

So to be on the safe side we would need to rename application/awt to
application/X-awt.

[1] http://www.faqs.org/rfcs/rfc2045.html

On 09.03.2005 01:31:24 Glen Mazza wrote:
 The application/awt MIME type doesn't exist.  I
 think Jeremias wanted this to be null instead for
 output types that lack a MIME type, correct?
 
 Thanks,
 Glen
 
 --- [EMAIL PROTECTED] wrote:
 
+/** The MIME type for AWT-Rendering */
 public static final String MIME_TYPE =
  application/awt;
 



Jeremias Maerki



Re: Integration of TIFFRenderer in FOP

2005-03-08 Thread Jeremias Maerki
Relationship to which PDF renderer? The one that directly creates PDF 
(PDFRenderer) or the one that creates PDF through JPS (normal
PrintRenderer as defined in the Wiki painting to a Graphics2D instance
provided by JPS) using a StreamPrintService? That's the two choices.
Obviously, you will be taking the latter approach. If you wait a bit
(until the common components area is set up) you'll have a neatly
separated package to create PDF using JPS because I'll be publishing my
proof-of-concept JPS StreamPrintService which you can build on.

Hmm, this gives me another thing to talk about over in XML Graphics
General.

On 09.03.2005 00:53:16 Peter B. West wrote:
 This approach is obviously of interest to me, and I will follow 
 developments closely.  The wiki page is very general.  If the 
 Java2DRenderer is to be the (abstract) technical foundation, what will 
 the relationship to the concrete PDF renderer be?  The wiki is vague on 
 this point.


Jeremias Maerki



Re: Good job! / Re: Integration of TIFFRenderer in FOP

2005-03-08 Thread Jeremias Maerki
Thanks to Glen for raising the issue. The ideal approach is if Oleg
would pack up his TIFFRenderer and donate it to the ASF accompanied with
a software grant [1], but Oleg is a FOP committer and has a CLA on file.
So if Oleg attaches a ZIP with the sources for the TIFFRenderer (ALv2
already applied) to a Bugzilla entry along with a note that we may
include it in FOP, that's good enough for me. It's not that the thing is
a big application in itself even though some people would argue works
like Renaud's AWT patch and Oleg's TIFFRenderer must go/run through the
Incubator.

[1] http://www.apache.org/licenses/#grants

On 09.03.2005 01:12:05 Glen Mazza wrote:
 Team,
 
 Oleg's TIFF Renderer is under the Mozilla license[1],
 not the Apache one (also apparently some of the code
 is from Sun?).  Is the former compatible with the
 latter?  If not, I would like Oleg to switch the
 license on it before we proceed further in putting it
 into FOP.
 
 Renaud--thanks for your fantastic work with the AWT
 Renderer.  You clearly have ace technical skills,
 enthusiasm, organization, and you write beautifully. 
 You have a bright future ahead of you.
 
 [Thanks also to Bertrand for sending Renaud our way. 
 This is the second quality developer--Peter Herweg
 being the other--that we have gotten from him since
 I've been on this project.]
 
 Regards,
 Glen
 
 [1] http://www.tkachenko.com/fop/tiffrenderer.html
 
 
 --- Renaud Richardet [EMAIL PROTECTED]
 wrote:
 
  Oleg,
  
  I'm currently working on the AWTRenderer. The basic
  idea is to create
  a Java2DRenderer which provides the (abstract)
  technical foundation.
  Other renderers can subclass Java2DRenderer and
  provide the concrete
  output paths [1].
  
  I think it would be a good idea to integrate your
  TIFFRenderer, as you
  propose in [2]. Would you like to integrate it
  yourself? Otherwise I
  would like to do it.
  
  Regards,
  Renaud
  
  [1]
  http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D
  [2] http://www.tkachenko.com/fop/fop.html
  



Jeremias Maerki



Re: Skype-conference on page-breaking?

2005-03-07 Thread Jeremias Maerki
Thanks, Luca.

I've had a nice casual talk on the phone with Simon, yesterday.
Essentially, we only talked about very high-level stuff, especially the
decision for a certain strategy (or two). You know I came up with the
idea to create a simpler best-fit strategy with no look-ahead for
invoice-style documents but maybe it would be possible to design your
obvious total-fit strategy in a way that it could be used as a best-fit
without look-ahead. The problem, like I mentioned already, is the
possible change of available IPD within a page-sequence which results in
a possible back-tracking and recalculation of vertical boxes.

Of course, if it's possible to stay with one page-breaking algorithm for
all use cases that would be best (because of the reduced effort), but
only if the algorithm is reasonably fast for invoice-style documents.
I'm repeatedly confronted with certain speed requirements in this case.
Since modern high-volume single-feed printers handle about 180 pages per
minute (continuous feed systems handle over 4 times that speed, but I
think that's neither relevant, nor realistic here) FOP should be able to
operate close to these 180 pages per minute for not too complex
documents on a modern server. That means 330ms per page. Not much. Of
course, in such an environment it is possible to distribute the
formatting process over several blade servers but I had to realize that
certain companies tend to prefer spending 100'000 dollars on a big
server than spending a lot less for a much faster CPU-power-oriented
setup. It seems to be hard to say good-bye to the old host systems. Well,
that's just like the reality looks like in my environment.

Simon, for example, is much more interested in book-style documents
where there are other requirements. Speed is not a big issue, but
quality is.

In the end, I think we need to rate the chosen approach in these two
points of view. These are very contradicting requirements and it's
something that seems quite important to me not to forget here.

Luca, do you think your total-fit approach may be written in a way to
handle changing available IPDs and that look-ahead can be disabled to
improve processing speed at the cost of optimal break decisions? If it's
ok for you (and feasible) I'd like to integrate what you already have
(in code) into that branch I was talking about. I would like to avoid
recreating something you've already started, even if it doesn't work
with the changes that happened in the last weeks. Even if we may create
two different strategies I'm sure that certain parts will be shared by
both approaches, like the creation of Knuth-style elements for the
PageLM. 

Some more comments inline:

On 04.03.2005 13:23:01 Luca Furini wrote:
 
 Jeremias Maerki wrote:
 
 Would you consider sharing what you already
 have? This may help us in the general discussion and may be a good
 starting point.
 
 Ok, I'll try to.
 
 The main change in the LineLM is that the line breaking algorithm does not
 select only the node in activeList with fewest demerits: all the nodes
 whose demerits are = a threshold are used to create LineBreakPositions,
 so for each paragraph there is a set of layout options (for example, a
 paragraph could create 8 to 10 lines, 9 being the layout with fewest
 demerits).

Hmm, that's a feature that I would say is something that only book-style
documents will need. Invoice-style documents could live without it.

 According to the value of widows and orphans, the LineLM creates a
 sequence of elements: besides normal lines, represented by a box, there
 are optional lines, represented by
   box(0) penalty(inf,0) glue(0,1,0) box(0)
 and removable lines
   box(0) penalty(inf,0) glue(1,0,1) box(0)
 A few complications arise if not every possible layout allows breaks
 between lines, but they all can be solved using boxes, glues and
 penalties (for example, if a paragraph needs 3 or 4 lines, if it uses 3
 it cannot be parted).

Also something that's not all too important for invoice-style documents,
although it can't hurt to have it.

 The BlockLM, and a block stacking LM in general, adds elements
 representing its children's spaces and keep condition, for example
 adding a 0 penalty or an infinite penalty according to
 child1.mustKeepWithNext(), child2.mustKeepWithPrevious() and
 this.mustKeepTogether().

That's certainly a must-have in any case.

 The PageLM, once it has the list of elements representing a whole
 page-sequence (or the content before a forced page break), calls the same
 breaking algorithm, using only a different selection method which leaves
 only one node in activeList.

That's the part where I have a big question mark about changing
available IPD. We may have to have a check that figures out if the
available IPD changes within a page-sequence by inspecting the
page-masters. That would allow us to switch automatically between
total-fit and best-fit or maybe even first-fit. A remaining question
mark is with side-floats as they influence

Re: Skype-conference on page-breaking?

2005-03-07 Thread Jeremias Maerki
I don't know why this is important to you but it's two to three months.

On 04.03.2005 12:40:04 Peter B. West wrote:
 Jeremias Maerki wrote:
  Sounds very interesting. Would you consider sharing what you already
  have? This may help us in the general discussion and may be a good
  starting point.
  
  My problem is that I have to deliver working page breaking with keeps,
  breaks, multi-column, adjustable spacing etc. in a relatively short
  period of time.
  
 
 How short?
 
 Peter
 -- 
 Peter B. West http://cv.pbw.id.au/
 Project Folio http://defoe.sourceforge.net/folio/



Jeremias Maerki



Re: FOP at ApacheCon Europe 2005?

2005-03-07 Thread Jeremias Maerki
FYI, I've just given myself a shove, followed Bertrand's suggestion and
submitted a session proposal for ApacheCon. I feel that our project
should be present there. I was also thinking about something like
hidden treasures in the XML Graphics project but I guess there's not
so much meat on that bone to fill one hour.

 ApacheCon Europe 2005 CFP submission
 
 Submitter: Jeremias Maerki [EMAIL PROTECTED]
 Title: Apache FOP: Optimizing speed and memory consumption
 Level: Experienced
 Style: 
 Orientation: Developer
 Duration: 60
 Categories: 
 Abstract:
 
 Apache FOP is the most popular XSL-FO implementation on the
 market. It is used in a wide variety of use cases to create documents
 in PDF, PostScript and other formats. This session will show a
 number of techniques to improve processing speed and and hints on how
 to handle things like OutOfMemoryErrors. It will also contain a
 short info block about the state and the future of the project.
 



On 12.02.2005 10:57:15 Bertrand Delacretaz wrote:
 Le 8 févr. 05, à 19:29, Jeremias Maerki a écrit :
 
  Most of you will probably have heard that ApacheCon Europe will be 
  happening in
  July. I think it would be great if FOP would somehow be visible there.
  There's a call for participation ending 2005-03-04. Any ideas?
 
 A recurring question in my consulting work is is FOP fast or what? or 
 more precisely how to tune XSL-FO for FOP to run efficiently, mostly 
 in view of avoiding memory bottlenecks.
 
 Me, I'm not using FOP hands-on enough these days to answer very 
 precisely, I usually just tell them to test their performance on large 
 documents very regularly during development, to avoid surprises.
 
 But maybe one of you FOP gurus could give a presentation with more 
 precise information about this?
 
 Just my 2 cents.
 
 -Bertrand



Jeremias Maerki



Re: future of FOP

2005-03-07 Thread Jeremias Maerki
Michael,

if you follow the fop-dev mailing list you will realize that the
development has not come to a stand-still. It is true that the last
release is almost two years old. We're in a redesign phase which tries
to address exactly the issue of keeps among other things. The redesign
took a lot longer than anticipated. But we're on the right track so we
can start releasing again later this year, complete with keeps.

If you can't work around the missing keeps (they work on table-rows) and
you need an immediate solution you will need to switch to a different
solution for the time being.

I understand that IBM is quite big in the document business. It would be
very interesting if IBM committed to supporting FOP like they do for
other open source projects here at the Apache Software Foundation. As
far as I know IBM even has its own implementation of XSL-FO although I
don't know if it's actively maintained.

On 07.03.2005 16:27:33 Michael Iwaniewicz wrote:
 
 Dear FOP developers,
 
 we are a big sw-development and decidedrecently to change or old
 bookmaster/afp based print componentto XSL-FO. As part of our
 solution we started to use FOP but run into formattingproblems in the area of 
 the
 keep-together and keep-with-nextoptions. 
 
 We got the impression that the FOP developmentcame to a kind of
 stand-still, since the current version is dated from2003. I just wanted
 to ask you if our impression is correct. We have nowto decide if we
 change from FOP to XEP or XSL-Formatter.
 
 Thanks for your help, Michael
 
 
 Michael Iwaniewicz
 CHIS Architecture
 Office: (43-1) 21145-6446
 Mobile:(43) (0) 664-618-5839



Jeremias Maerki



Re: FOP at ApacheCon Europe 2005?

2005-03-07 Thread Jeremias Maerki
Cool, that would be great stuff. Let's hope your boss lets you off the
leash.

On 07.03.2005 23:57:50 J.Pietschmann wrote:
 Jeremias Maerki wrote:
  I was also thinking about something like
  hidden treasures in the XML Graphics project but I guess there's not
  so much meat on that bone to fill one hour.
 
 Well, there should be enough for an hour, at least in theory.
 I couldn't convice (yet) my boss that I have an important mission
 in Stuttgart in July. If I could, I'd probably talk about:
 - Handling fonts in Java, why the AWT font and text rendering
   subsystem is lame, and what FOP, Batik and perhaps others would
   expect from an API.
 - How to implement flowing text, line breaking and hyphenation
   efficiently; why the Java BreakIterator and other parts of the Java
   Unicode support sux0rs; what's behind TR14; Unicode normalization of
   text before looking it up in a dictionary, and efficient implementation
   of said dictionary for looking up all substrings in a word (using a
   trie, a PATRICIA tree or whatever)
 - Talk about the question why the algorithms aren't simply copied
   from Gecko (the Mozilla layout engine)
 
 Now that the deadline has been extended, I'll attempt it again.
 
 J.Pietschmann



Jeremias Maerki



Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-04 Thread Jeremias Maerki
An alternative link to the documents Renaud referred to:
http://www.le-hacker.org/hacks/pagination/

There are a few other quite interesting documents on layout questions,
particularly something about tables which might come in handy later.

On 04.03.2005 02:14:56 Renaud Richardet wrote:
 Vincent Hennebert wrote:
  By looking for this reference, I found the following article:
  www.pi6.fernuni-hagen.de/publ/tr234.pdf
  It's entitled 'On the Pagination of Complex Documents' (actually it's also
  referencing Plass). 
 
 There's another article, where the top level of the algorithm is
 presented (page 8).
 http://www.pi6.fernuni-hagen.de/publ/tr205.pdf
 
 Those 2 articles are summaries of a book. The link to command the book
 can be found at the bottom of
 http://web.informatik.uni-bonn.de/I/research/Pagination/
 
 Renaud



Jeremias Maerki



Re: Skype-conference on page-breaking?

2005-03-04 Thread Jeremias Maerki
Ok then, I'll call you Sunday evening 19.00 CET if nothing goes wrong.
The others interested will find me in Skype.

FYI, I'll be out of touch from later today until Sunday afternoon.

On 03.03.2005 21:46:55 Simon Pepping wrote:
 On Thu, Mar 03, 2005 at 08:34:54PM +0100, Jeremias Maerki wrote:
  I've bought some SkypeOut credits now. Funny thing: It's cheaper to call
  Simon in the Netherlands than to call someone in Lucerne via PSTN. 
  
  Anyway, I'd like to ask if we could hold to a brainstorming conference
  call on page breaking either Sunday evening or next Monday or Tuesday
  somewhere between 8:00 and 24:00 CET. Of course, on my wish list there
  are Simon, Finn and Luca. I'm happy to call either of you on your normal
  phone via SkypeOut if you don't have broadband. I hope I can get at
  least one of you three on the line. Others are invited to listen in and
  contribute, of course. Max. number in the conference is four people with
  Skype.
 
 Sunday evening is OK. Monday and Tuesday after working hours is OK. I
 could be available from 16.00 hrs, but I would prefer after 19.00 hrs
 CET. There is no way I can do this at the office.
 
 Regards, Simon
 
 -- 
 Simon Pepping
 home page: http://www.leverkruid.nl



Jeremias Maerki



Re: Skype-conference on page-breaking?

2005-03-04 Thread Jeremias Maerki
Sounds very interesting. Would you consider sharing what you already
have? This may help us in the general discussion and may be a good
starting point.

My problem is that I have to deliver working page breaking with keeps,
breaks, multi-column, adjustable spacing etc. in a relatively short
period of time.

On 04.03.2005 11:09:42 Luca Furini wrote:
 
 Jeremias Maerki wrote:
 
 Anyway, I'd like to ask if we could hold to a brainstorming conference
 call on page breaking either Sunday evening or next Monday or Tuesday
 somewhere between 8:00 and 24:00 CET. Of course, on my wish list there
 are Simon, Finn and Luca. I'm happy to call either of you on your normal
 phone via SkypeOut if you don't have broadband. I hope I can get at
 least one of you three on the line.
 
 I'v very interested in page breaking, and I would be happy to contribute.
 
 Unfortunately, I'm not much used to speaking english :-(, so I think I
 would be much more comfortable with the idea of communicating via written
 words!
 
 As I have said before (or maybe I forgot to ...) I have done a few
 experiments trying to use Knuth's algorithm in page braking, and I have a
 working implementation which handles only some block level formatting
 objects (blocks and lists) and simplified documents (no footnotes or
 floats, at the moment, and pages with equal length and width), but it has
 some (I hope) interesting features: for example, it is able to adjust the
 number of lines used for each paragraph in order to both fill the pages
 and avoid orphans and widows.
 In a few words, using the box - penalty - glue model it is possible to
 represent paragraphs with an adjustable number of lines.
 
 I started working on it a few months ago, and I could not keep it updated
 with all the changes, but if you are interested I could try and recreate
 these features using the most recent code. Anyway, this could be done
 after we have reached a basic implementation.
 
 Regards
 Luca



Jeremias Maerki



Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Jeremias Maerki
While looking for material on page breaking I found several references
to this document:

http://wwwlib.umi.com/dissertations/fullcit/8124134

Does anyone know if it's worth ordering and waiting for it? The
unfortunate thing is that they don't seem to have a PDF version that I
could download immediately for a reasonable fee.

Thanks,
Jeremias Maerki



Re: [XML Graphics - FOP Wiki] Updated: PageLayout

2005-03-03 Thread Jeremias Maerki
I've tried to think this case through. Simon's suggestion for a special
penalty is intriguing. It handles the case for table borders where we
don't simply have an x or 0 situation (like penalty and glue provide),
but we have a x or y situation.

On the other side Luca is probably right that we should try to handle as
much as possible with the existing elements. However, Luca's example
does not fully resolve in my brain. The penalty, for example, must not
be infinite or it will not be eligible for break possibility. A legal
break is defined by Knuth as a number b such that either
(i) xb is a penalty item with pb  infinity, or (ii) xb is a glue item
and xb-1 is a box item. As far as I can see Luca's example doesn't
contain any legal break, but I guess that was simply an oversight.

The big problem I still have with both your examples is that the table
header is very special in terms of the standard Knuth model. This model
doesn't allow for conditional items at the beginning of a line. What
Luca did in his example looks to me like forcing the model to do
something it wasn't designed for. I'm a bit sceptical that the code will
be able to identify such special conditions reliably.

In this case I think we would have to introduce a special element that
gets active if such a penalty was triggered on the last line/page (a
carryover-penalty or something like that).

In the end I think that all the elements after a chosen break may be
invalid anyway if the available IPD changes (for example when the n+1
page is landscape while the page n was portrait). In this case all
non-finalized elements have to be recalculated due to different break
decisions in the line layout managers and different values coming from
page-number(-citation) elements. [1]

I wonder how other systems cope with this. Information on this seems to
be very rare, at least when googling with the Knuth model in mind.

Head smoking, digging deeper...

[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout/KnuthElementEvaluation

On 28.02.2005 10:15:39 Luca Furini wrote:
 
 Simon Pepping wrote:
 
 +=== Space specifiers ===
 +
 +When the space specifiers resolve to zero around a page break, we are
 +in the same situation as that of a word space in line breaking. It is
 +represented by the sequence `box - glue - box`.
 
 I add just a few thoughts about this subject.
 
 If there cannot be a break between the two block (the first has
 keep-with-next || the second has keep-with-previous || their block father
 has keep-together), the representation can be box - infinite penalty -
 glue - box.
 
 +=== Possible page break between content elements ===
 +
 +Here the most general situation is that when the content is different
 +with and without page break:
 + * content Cn when there is no page break,
 + * content Ca at the end of the page before the page break,
 + * content Cb at the start of the page after the page break.
 +
 +An example of this situation is a page break between table rows:
 +
 +{{{
 +no page break:page break:
 +
 +- -
 +  row 1 row 1
 +- -
 + border n  border a
 +- -
 +  row 2footer
 +- -
 +  page break
 +  -
 +   header
 +  -
 +   border b
 +  -
 +row 2
 +  -
 +}}}
 +
 +This situation cannot be dealt with using Knuth's box/glue/penalty
 +model.
 
 Maybe there is no need to create new kinds of elements (not that it's
 forbidden :-) , only the fewer they are, the simpler the algorithm is).
 
 Header and footer, with their borders, are duplicated around each break if
 table-omit-*-at-break is false; so, at each break the total height
 increases by (border a + footer + header + border b) and decreases by
 border n.
 
 Here is a different representation which uses normal penalties; there are
 two rows whose bpd is h1 and h2, header and footer with bpd hH and hF,
 border before the footer , border after the header and border between rows
 hA, hB and hN.
 
 box(h1) - penalty(inf, hH + hA + hB + hF) - glue(hN) - box(h2) - box(hB +
 hF) - box(hH + hA)
 
 If there is no break, the overall bpd is (hH + hA + h1 + hN + h2 + hB +
 hF), otherwise the first piece has bpd (hH + hA + h1 + hB + hF) and the
 second one (hH + hA + h2 + hB + hF), and the border between the rows is
 ignored.
 
 The elements representing the header and its border are moved at the end
 of the sequence, but I don't think this is could be a real problem: the
 TableLayoutManager would place it at its right place when adding areas.
 
 Regards
 Luca
 



Jeremias Maerki



Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Jeremias Maerki

On 03.03.2005 16:19:24 Victor Mote wrote:
 Jeremias Maerki wrote:
 
  While looking for material on page breaking I found several 
  references to this document:
  
  http://wwwlib.umi.com/dissertations/fullcit/8124134
  
  Does anyone know if it's worth ordering and waiting for it? 
  The unfortunate thing is that they don't seem to have a PDF 
  version that I could download immediately for a reasonable fee.
 
 Wow. This looks like it is very valuable. I have ordered it for my own use,
 and I'll be glad to give you a book review when it arrives to help you
 decide whether it is worthwhile for you or not.

I will probably order it anyway because I need it yesterday. :-) That's
why I wanted the PDF version which they don't seem to have. Sigh.

 I am especially interested in the summary's comment: For certain simple
 badness functions, the pagination problem is NP-complete; Dealing with that
 challenge is the likely tricky spot in all of this. My intuition has always
 been that the page-breaking problem is much more complicated than the
 line-breaking one, partly because lines must be laid out to even think about
 page-breaking (and line lengths can change as they move around), partly
 because you are effectively working with changes in two dimensions instead
 of one, and partly because there seem to me to be a lot more variables in
 the problem. I am hoping to find some insight into the detection and
 workarounds for the NP-complete situations.

I've found other references to discussion about communication between
line and page breaking algorithms. But that stuff was mostly
overview-style and written in a language I don't understand well:
universitary language. That's probably the first time I regret stopping
university after one semester because I hate mathematics. :-)

 Note that Stanford is Knuth's school, the date year is the same as that of
 Chapter 3 of Knuth's Digital Typography, and that the author is the
 co-author of that article. It may be possible to infer the same information
 from looking at the TeX source code. Also, another source of similar
 information would be Volume I of Knuth's Computers and Typesetting, aka
 The TeXbook. It is essentially a commentary on TeX, by Knuth. Chapter 15
 is entitled How TeX Makes Lines into Pages.

I haven't dared look into the TeX source code, yet, but I've read most
of the chapter you mention. Didn't really help because there are many
many TeX-specific things in there.

 You guys are way ahead of me in terms of thinking about how to implement
 this stuff. As you know, my approach has been to leave this stuff for last,
 preferring instead to solve the outer-layer problems first, and provide for
 multiple implementations that can be improved in parallel. However, I have a
 great interest in your efforts, and will be glad to help any way that I can.
 And, FWIW, I think you are on the right general track, in this regard at
 least.

I very much hope so. But it becomes more and more apparent that this
will be the greatest challenge in my programmer's life. Wow indeed.


Jeremias Maerki



Re: Plass, Michael Frederick: Optimal Pagination Techniques for Automatic Typesetting Systems

2005-03-03 Thread Jeremias Maerki
Actually, I haven't. The RTF edition idea (which I haven't discarded,
yet, just postponed due to time shortage) is still very high on my
private priority list. As you can guess there's currently another one
which comes first.

On 03.03.2005 18:31:12 Glen Mazza wrote:
 Happy to see how you have reprioritized your efforts
 over the past two months [1], and much, much for the
 better.
 
 Glen
 
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
  
  I very much hope so. But it becomes more and more
  apparent that this
  will be the greatest challenge in my programmer's
  life. Wow indeed.
  
  
  Jeremias Maerki
  
  
 
 [1] http://marc.theaimsgroup.com/?l=fop-devm=110495579414655w=2



Jeremias Maerki



Re: Skype-conference on page-breaking?

2005-03-03 Thread Jeremias Maerki
I've bought some SkypeOut credits now. Funny thing: It's cheaper to call
Simon in the Netherlands than to call someone in Lucerne via PSTN. 

Anyway, I'd like to ask if we could hold to a brainstorming conference
call on page breaking either Sunday evening or next Monday or Tuesday
somewhere between 8:00 and 24:00 CET. Of course, on my wish list there
are Simon, Finn and Luca. I'm happy to call either of you on your normal
phone via SkypeOut if you don't have broadband. I hope I can get at
least one of you three on the line. Others are invited to listen in and
contribute, of course. Max. number in the conference is four people with
Skype.

On 01.03.2005 23:31:16 Jeremias Maerki wrote:
 Maybe I could hook you into a Skype conference by using SkypeOut. It's pretty
 cheap to call to the Netherlands. According to the FAQ this is possible.
 
 On 01.03.2005 22:26:50 Simon Pepping wrote:
  On Tue, Mar 01, 2005 at 03:09:46PM +0100, Jeremias Maerki wrote:
   To speed things up could we hold a conference (using Skype, for example)
   to discuss further details on page-breaking? I'd volunteer to sum up any
   results during that discussion for the archives. I have Finn on my Skype
   radar already.
  
  I do not have a broadband connection, and therefore no Skype or other
  VoIP.
 
 
 Jeremias Maerki



Jeremias Maerki



Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
I'd rather not work on HEAD directly because after creating the basics
for the new mechanism the whole thing will probably not work for some
time (probably 2-4 weeks). But I'd like to be able to check in early so
people can review. I expect that the life time of the branch will not
exceed 8 weeks. So there's almost no chance that alt-design is repeated,
especially since the basic LM infrastructure will not be altered big
time and it looks like we are all going in the same direction for the
new page-breaking. It's clear that it has to be done and it seems to be
moveing in the direction of a derived Knuth approach. It's much like the
migration to the Knuth line breaking and it's mostly the block-level LMs
that will be affected. People can continue to work on HEAD during that
time as long as nothing serious is altered in the block-level LMs which
would make merging difficult.

Before I can kick off we need to agree to the general approach for the
algorithm and clear a few details so we are reasonably sure that it'll
work. Once we have that the plan for the branch should not be a big deal
if we take the above into account.

On 02.03.2005 13:16:42 Glen Mazza wrote:
 
 --- Chris Bowditch [EMAIL PROTECTED] wrote:
 
   
   As for the plan to implement a new page-breaking
  mechanism: I've got to
   do it now. :-) I'm sorry if this may put some
  pressure on some of you.
   I'm also not sure if I'm fit already to tackle it,
  but I've got to
   do it anyway. Since I don't want to work with a
  series of patches like
   you guys did earlier, I'd like to create a branch
  to do that on as soon
   as we've agreed on a strategy. Any objections to
  that?
  
  If we are going to branch the code for this then we
  need to make sure we have 
  a plan to merge the branch back once we are
  confident in the new page breaking 
  algorithm. This plan (which should be agreed before
  branching takes place) 
  should include an acceptance procedure, e.g. will a
  single -1 be able to 
  prevent the code being merged back? We dont want to
  end up with another 
  alt-design, which eventually moved to source
  forge!!!
  
  Chris
  
 
 Either way is fine with me, but Chris brings up a very
 valid point.  If you can tolerate and keep up with my
 minor code housekeeping from time to time in some of
 the layout managers (currently mostly PSLM), feel free
 to work from HEAD directly instead if you wish.
 
 Glen



Jeremias Maerki



Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
Where did you find such a suggestion? I'd be interested to know if
there's a hint in this direction in the spec. I thought it was up to the
implementation to decide the strategy.

I think the way we're now taking in our discussion suggests that we're
not going to do a first-fit strategy at all. If we're really going down
the two-strategy path we'll probably end up with a best-fit strategy and
a total-fit or best-fit plus look-ahead. (See Simon's list [1]) But
that's something we still need to figure out together.

[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout

On 02.03.2005 14:48:17 Glen Mazza wrote:
 Just a sanity check here, the XSL specification seems
 to suggest always the first-fit strategy for page
 breaking *except* where keeps are explicitly
 specified.  Am I correct here?  And, if so, is what
 you're planning going to result in an algorithm that
 will help us do this?


Jeremias Maerki



Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki
Thanks. I think this has only to do with the rules to handle keeps and
breaks and how to resolve conflicts. I don't think, however, that these
parts create a restriction which tells us what page-breaking strategy to
pursue. We could probably run with a first-fit strategy and still
fulfill the rules below if we accept a lot of backtracking. But as Simon
suggested, this seems to be a poor approach.

Keeps and breaks are only part of what a page breaking algorithm has to
deal with. See [3].

[3] http://wiki.apache.org/xmlgraphics-fop/PageLayout/InfluencingFeatures

On 02.03.2005 16:44:17 Glen Mazza wrote:
 I'm unsure here.  My interpretation comes from two
 places: 
 
 1.) Section 4.8, the last paragraph of [1]:
 
 The area tree is constrained to satisfy all break
 conditions imposed. ***Each keep condition must also
 be satisfied***, except when this would cause a break
 condition or a stronger keep condition to fail to be
 satisfied.
 
 i.e., keep conditions need to be satisfied.
 
 2.) The definitions of the three keep-[] properties
 [2] each have a initial value of auto, meaning
 There are no keep-[] conditions imposed by this
 property.
 
 So by default, if the user does not explicitly specify
 keep properties, e.g., keep-together.within-page, no
 text, pictures, etc. are to be kept together on the
 same page, if they wouldn't already be so due to
 free-flowing (i.e., first-fit) text.  Everything would
 become free-flowing in order to obey the stylesheet
 writer's specifications.
 
 Just my $0.02.
 
 Thanks,
 Glen
 
 [1]
 http://www.w3.org/TR/2001/REC-xsl-20011015/slice4.html#keepbreak
 
 [2]
 http://www.w3.org/TR/2001/REC-xsl-20011015/slice7.html#keep-together
 
 
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  Where did you find such a suggestion? I'd be
  interested to know if
  there's a hint in this direction in the spec. I
  thought it was up to the
  implementation to decide the strategy.
  
  I think the way we're now taking in our discussion
  suggests that we're
  not going to do a first-fit strategy at all. If
  we're really going down
  the two-strategy path we'll probably end up with a
  best-fit strategy and
  a total-fit or best-fit plus look-ahead. (See
  Simon's list [1]) But
  that's something we still need to figure out
  together.
  
 
 If we ever have multiple page-breaking options, it can
 be a user-defined configuration switch.  No problem
 there.
 
 Glen
 
 
  [1]
  http://wiki.apache.org/xmlgraphics-fop/PageLayout
  
  On 02.03.2005 14:48:17 Glen Mazza wrote:
   Just a sanity check here, the XSL specification
  seems
   to suggest always the first-fit strategy for page
   breaking *except* where keeps are explicitly
   specified.  Am I correct here?  And, if so, is
  what
   you're planning going to result in an algorithm
  that
   will help us do this?
  
  
  Jeremias Maerki
  
  



Jeremias Maerki



Re: page-breaking strategies and performance

2005-03-02 Thread Jeremias Maerki

On 02.03.2005 17:05:55 Glen Mazza wrote:
 Yes, I'm not in Simon's league here--I know very
 little about TeX--so I'll defer to you two on this
 issue.

I'm also still struggling. :-)

  Just try to make sure that the final algorithm
 will help us support the keep-* properties.

Yes, the algorithm MUST be able to handle full keep support (among other
things). That's part of why we need a new approach. The present one
doesn't quite fit the picture, yet. Thankfully, with the new design we
don't have to again rewrite the whole FOP. The present approach was very
good to point us in the right direction and most of the effort already
invested is not lost. We just have to improve a specific part.

Jeremias Maerki



page-breaking strategies and performance

2005-03-01 Thread Jeremias Maerki
I finally have Knuth's Digital Typography and let myself enlighten by
his well-written words. In [1] Simon outlined different strategies for
page-breaking, obviously closely following the different approaches
defined by Knuth. At first glance, I'd say that best-fit is probably
the obvious strategy to select, especially if TeX is happy with it.
Obviously, it can't find the optimal solution like this but the
additional overhead (memory and CPU power) of a look-ahead/total-fit
strategy is simply too much and unnecessary for things like invoices and
insurance policies which are surely some of the most popular use cases
of XSL-FO. Here, speed is extremely important. People writing
documentation (maybe using DocBook) or glossy stock reports have
additional requirements and don't mind the longer processing time and
additional memory requirements. This leads me to the question if we
shouldn't actually implement two page-breaking strategies (in the end,
not both right now). For a speed-optimized algorithm, we could even
think about ignoring side-floats.

Obviously, in this model we would have to make sure that we use a common
model for both strategies. For example, we still have to make sure that
the line layout gets information on the available IPD on each line, but
probably this will not be a big problem to include later.

An enhanced/adjusted box/glue/penalty model sounds like a good idea to
me especially since Knuth hints at that in his book, too. There's also a
question if part of the infrastructure from line breaking can be reused
for page breaking, but I guess rather not.

As for the plan to implement a new page-breaking mechanism: I've got to
do it now. :-) I'm sorry if this may put some pressure on some of you.
I'm also not sure if I'm fit already to tackle it, but I've got to
do it anyway. Since I don't want to work with a series of patches like
you guys did earlier, I'd like to create a branch to do that on as soon
as we've agreed on a strategy. Any objections to that?

[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout 

Jeremias Maerki



Skype-conference on page-breaking?

2005-03-01 Thread Jeremias Maerki
To speed things up could we hold a conference (using Skype, for example)
to discuss further details on page-breaking? I'd volunteer to sum up any
results during that discussion for the archives. I have Finn on my Skype
radar already.

Jeremias Maerki



Re: [XML Graphics - FOP Wiki] Updated: PageLayout

2005-03-01 Thread Jeremias Maerki
Simon, I've tried to think your example through. If I read the spec
right about space resolution then I get the impression that we may need
to do more in this area than find a suitable box/glue/penalty
combination. There may be several spaces which need to be taken into
account during resolution. There's the precedence and the conditionality
that needs to be evaluated. I think we may need to create special
elements that can hold this information (or reference it). They need to
be distinguishable so we can apply the resolution rules properly.

I believe your example should then look like this:

- box
- penalty (w=0, p=infinite)
- space
- glue (w=0, y=0, z=0)
- space
- penalty (w=0, p=infinite)
- box


A more complex example would look like this:

fo:block space-after=5pt
  fo:blocka line/fo:block
  fo:block space-after=3pt
 blah blah
  /fo:block
/fo:block
fo:block space-before=10pt
  blah bla
/fo:block

- box (a line)
- box (blah blah)
- penalty (w=0, p=infinite)
- space (w=3pt, ref to the space property)
- penalty (w=0, p=infinite)
- space (w=5pt, ref to the space property)
- glue (w=0, y=0, z=0)
- space (w=10pt, ref to the space property)
- penalty (w=0, p=infinite)
- box

The algorithm would have to track down the space element before and
after the break and then apply the space resolution rules. The space
elements would behave much like glue elements.

What do you think?

On 25.02.2005 22:50:17 SimonPepping wrote:
 +=== Space specifiers ===
 +
 +When the space specifiers resolve to zero around a page break, we are
 +in the same situation as that of a word space in line breaking. It is
 +represented by the sequence `box - glue - box`.
 +
 +When the space specifiers do not resolve to zero around a page break,
 +we are in the same situation as that of a word space in line breaking
 +in the case of centered lines. It is represented by the sequence 
 +{{{
 +box - infinite penalty - glue(ha) - zero penalty - glue(hn-ha-hb) - zero 
 width box - infinite penalty - glue(hb) - box
 +}}}
 +where ha is the bpd of
 +the space-after before the page break, hb is the bpd of the
 +space-before after the page-break, hw is the space when there is no
 +page break.


Jeremias Maerki



Re: page-breaking strategies and performance

2005-03-01 Thread Jeremias Maerki

On 01.03.2005 22:25:12 Simon Pepping wrote:
 On Tue, Mar 01, 2005 at 07:52:27AM -0700, Victor Mote wrote:
  Jeremias Maerki wrote:
  
   processing time and additional memory requirements. This 
   leads me to the question if we shouldn't actually implement 
   two page-breaking strategies (in the end, not both right 
   now). For a speed-optimized algorithm, we could even think 
   about ignoring side-floats.
   
   Obviously, in this model we would have to make sure that we 
   use a common model for both strategies. For example, we still 
   have to make sure that the line layout gets information on 
   the available IPD on each line, but probably this will not be 
   a big problem to include later.
  
  This is an excellent idea. It has from time to time gone under the moniker
  LayoutStrategy or pluggable layout. To do it without duplicating everything
  requires that the other pieces of the system be modularized, the concerns
  separated so that they can be reused. The upside is tremendous and the cost
  pays for itself in developer productivity.
 
 The idea of having two page breaking strategies is OK. But it is also
 a goal that is yet far over the horizon.

Right. What I'd like to achieve is having a usable layout engine with
the minimum of effort for most use cases but without blocking our way in
terms of full compliance like what happened with the old code base. I
also don't want to invest to much time in an infrastructure to support
pluggable strategies, only that we keep it in mind while we build the
first one.

 I hope this is smaller than having pluggable layout.

My hope, too. The critical part is to determine the model that helps us
express all the elements of the XSL-FO standard.

 We should try to
 express the layout constraints in a simple language, which can be used
 by the algorithms of both strategies. Knuth's model is an effort to
 achieve that, and a PageLayoutManager which receives the Knuth
 elements and invokes the appropriate algorithm goes with it.

That's what I'm currently trying to figure out. I guess we'll need to
sketch all the different layout elements that we need to support like
you started.

 Such a setup should not only enable multiple page breaking strategies,
 but also help us implement a simple strategy to start with, and
 gradually evolve it to a higher level of sophistication.

That's the idea.


Jeremias Maerki



Re: remove build.bat and build.sh?

2005-02-28 Thread Jeremias Maerki
I'm +1 on that. It's something I remember mentioning myself. I heard
people say that this is best pratice not to have build.sh/bat.

On 26.02.2005 14:14:21 Glen Mazza wrote:
 Team,
 
 Build.bat and build.sh just call ant internally
 today (and tell them to get Ant if it is not available
 on their machine)--I would like to move these
 instructions for how to download  activate Ant to our
 README file instead, and remove these two files.  (The
 check for JAVA_HOME is already done by Ant, so nothing
 lost there.)  Are we at the stage yet that we can rely
 on just a build.xml?
 
 With this change, instead of calling build to start
 a build, the user will just type ant instead.  (The
 README file will tell them this.)  I suspect we'll get
 a few more emails on the ML from people who don't read
 the README file, but learning a little about Ant--if
 only the fact that they need to type ant--is
 probably a Good Thing for them anyway.
 
 Thanks,
 Glen



Jeremias Maerki



Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Jeremias Maerki
 track of
 the current position with the variables currentIPPosition and 
 currentBPPosition. 

Mostly related to omissions in startVParea I think.

 Images: I can't update the currentIPDPosition and currentBPDPosition for
 Image-areas. The Viewport associated with the image doesn't have any bpd
 associated with it. Is this normal?

No. For external-graphics and instream-foreign-object there are still a
few gaps in the LMs.

 The enclosed image doesn't have ipd/bpd
 either. Again: is this normal so? I have a workaround in mind (getting those
 values through the FopImage), but it doesn't sound right. 

In this case it is probably better to fix the LMs. I've started doing
that but haven't finished. ATM this is lower priority for me. I can send
you my current code if you want to try to fix it. Shouldn't be so
difficult.

 I implemented a simple .bmp rendering (BMPReader.java). It only supports 8-bit
 and 24-bit uncompressed windows bitmap images. I found this code on the net. I
 know you had problems with licences and I don't want to raise an issue here. I
 did this implementation more for myself than anything. If there's a better way
 to render .bmp (JAI?), let me know. Otherwise, I could try to convince the
 author to donate the code in conterpart of some fine chocolate :)

This should not be necessary. We have a BMP implementation in 
org.apache.fop.images.
The BMP bitmaps should be loaded through that mechanism. Your approach
only fixes AWT/Java2D and not PDF, PS etc. The only image types that
should be allowed to be treated in a special way are XML-based formats,
EPS and JPEG.

 SVG + External Objects rendering is very alpha. 

No problem. This is work in progress after all.

 renderTextDecoration(InlineArea) seems to work, even if it's not implemented??

Huh? It was you who moved the implementation up from PDFRenderer to
AbstractRenderer. That's how you implemented it. Inheritance!

 renderViewport is overriden in PDFRenderer to allow clip(). Is this feature 
 also
 needed in AWTRenderer?

Yes.

BTW, Using Graphics.create() you should be able to create a copy of the
current Graphics2D object. By pushing the old one on a stack and
overwriting the graphics member variable should should be able to create
the same effect as with currentState.push()/saveGraphicsState() in
PDFRenderer.startVParea () and currentState.pop()/restoreGraphicsState
()in endVParea(). When leaving a VP area you can simply restore an older
Graphics2D object for the stack and continue painting. This will undo
any transformations and state change done in the copy used within the VP
area. See second paragraph in javadocs of java.awt.Graphics.

 
 = What's next = 
 
 - fix the bugs described here 
 - implement the remaining features
 - test the renderer on more complex files 
 - implement what's described on the wiki FopAndJava2D [1]
 
 
 In the code, I used the following conventions: FIXME for the points I would 
 like
 you to review before checking the code in. And TODO for the points I still 
 have
 to work out (so please leave them). If someone using eclipse could mail me his
 formatter (PreferencesJavaCode StyleFormatter, then Export profile), that
 would be nice.
 
 Any comments or suggestions most welcome. Again, please let me know if I'm 
 doing
 things the right way. 
 
 I wish you a nice weekstart.
 Renaud
 
 [1] http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D

I'll let you improve your patch a bit before applying it. As I said, I
think you're going in the right direction. I'm looking forward to
committing your changes when you're happy with the results.

Another thought: One of my low-priority tasks is to create a little
application that renders a test suite with all of FOP's renderers
creating bitmap images for each generated document and ultimately
creating a little website that lets us compare the output. PDFs and PS
files can be converted to bitmaps using GhostScript. Maybe you might
want to write such a thingy. I won't get to it before I get to updating
the PS renderer to full quality.


Jeremias Maerki



Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Jeremias Maerki
Thanks for bringing this up. I almost forgot.

I'd be in favor of integrating Victor's improvements in this area.
However, I'd also be inclined to gently nudge you, Victor, to bring the
font stuff back to Apache into the XML Graphics Commons area once that's
set up. But I wouldn't have a problem to use your code from your
SourceForge location for the moment. We haven't talked, yet, what you'd
think about that. :-)

On 28.02.2005 17:20:32 Victor Mote wrote:
 1. FOray has factored the FOP font logic into a separate module, cleaned it
 up significantly, and made some modest improvements. A few weeks ago, I
 aXSL-ized it as well, which means that it is written to a (theoretically)
 independent interface:
 http://cvs.sourceforge.net/viewcvs.py/axsl/axsl/axsl-font/src/java/org/axsl/
 font/
 
 I say theoretically because the aXSL interface was simply extracted from
 the FOray code, and FOray is almost certainly the only aXSL implementation
 available ATM. The point is that someone *could* write another aXSL
 implementation that would work seamlessly with FOP. The only cost would be
 the instantiation of the brand X FontServer implementation instead of the
 FOray FontServer implementation.
 
 I think there is general support within FOP to implement the FOray/aXSL font
 work in the FOP 1.0 code, but so far no one has actually taken the time to
 do it. If you get into messing with fonts at all, I highly recommend that
 FOray be implemented before doing anything else. I will be happy to support
 efforts to that end.


Jeremias Maerki



Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Jeremias Maerki
I think you misunderstood. I wanted to suggest transferring (not
copying/forking) these parts over to Apache with you as a committer in
the Commons part. That would make it mostly your decision. I'm all
against duplication of efforts. Actually, it was the motivation for this
post. At Apache you'd have a bigger audience as well as a bigger chance
of finding people willing to help. And I don't see a big risk for
disputes as there were for the overall approach for FOP.

It was just an idea in the hopes of bringing people back together to
work on things with little to no potential for disagreements.

On 28.02.2005 19:33:05 Victor Mote wrote:
 Jeremias Maerki wrote:
 
  Thanks for bringing this up. I almost forgot.
  
  I'd be in favor of integrating Victor's improvements in this area.
  However, I'd also be inclined to gently nudge you, Victor, to 
  bring the font stuff back to Apache into the XML Graphics 
  Commons area once that's set up. But I wouldn't have a 
  problem to use your code from your SourceForge location for 
  the moment. We haven't talked, yet, what you'd think about that. :-)
 
 Hmmm. This is certainly an Apache decision, not mine. If it works better for
 you to have the code a part of an Apache project, you are certainly welcome
 to do that. IMO, it would result in a lot of unnecessary duplication of
 effort. I used to think that duplication of effort was the greatest evil to
 be avoided, but my experience on FOP has expanded my horizons a bit --
 pulling in opposite directions is worse. Still, duplication should be
 avoided if possible.
 
 My suggestion would be the following: 1) Write your font logic to the aXSL
 interface and use FOray as the implementation of that interface. 2) As
 improvements to font logic are needed, ask for them. I'll do my best to
 accommodate them within FOray. 3) If 2 proves unsatisfactory, I will be
 happy to consider adding some Apache people as committers on FOray
 (actually, I'll be glad to do that anyway). 4) If 3 becomes unsatisfactory,
 fork FOrayFont into an Apache project and start hacking away, or start a new
 project that uses the aXSL interface. 5) If the aXSL interface is inadequate
 and for any reason can't be changed, fork it and improve as necessary.
 
 Such a scheme allows us to be optimistic that we will be able to work
 together, but protects everybody in case we can't.
 
 Victor Mote
 



Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-24 Thread Jeremias Maerki

On 25.02.2005 07:21:25 Glen Mazza wrote:
snip/

For the moment I'm not going to answer the veto itself. Your veto makes
this situation a one against one. I have presented my reasons for the
change and therefore, I request feedback from the rest of the committers
on this matter even if it's just a short message.

 Jeremias, I gave you a full, thorough, and
 respectfully written explanation of the issues
 involved.  Not only did you mostly ignore it, but in
 your response you chose to use my earlier smaller
 email in order to give others the impression that I
 had nothing more to say.  This is terrible leadership
 on your part--railroading a change without discussion
 and refusal to discuss the change afterwords.  I
 simply can't support this behavior, hence my veto.

It may well be that I'm overreacting here. If that is so, then I'd like
an honest feedback from additional members in the team. You must see
that with your history I learned to treat your vetoes with caution
because of the many times you changed a -1 to a +1 later after a long
discussion and a lot of power spent. There's tension between us two and
that's bad. ATM I don't know how to resolve it. I tried to be as open as
possible and to address any concerns you have. You have repeatedly
brought very good points and for that I'm glad but you had to withdraw
several vetoes after starting to realize that you were wrong and I've
also seen behaviour from your part that I don't like. For example,
starting sentences with Mein Freund, bla bla and then later accusing
someone else in a different thread of being disrespectful. I didn't say
anything about it then. (Also, apologies to Renaud for not speaking up.
I didn't want to pour any oil into the fire at that time.) I tried to
overlook that, but I have my limits. I sometimes wonder if you're not
more of a blocker in this project than a pusher. I don't think I'm the
only one thinking like this. You know what happend during the creation
of the XML Graphics PMC.

 BTW, letting yourself be known to the W3C by writing
 to them on occasion would appear to be a smart move
 for you--I don't know why you are fighting this.

I'm not fighting this. I've had no compelling reason and spare time to
do this, yet. The current issue is no reason for me to write anything to
the WG.

Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/fo/flow TableBody.java

2005-02-23 Thread Jeremias Maerki
FOP 0.20.5 ignores an empty table-body, no error message.
XEP 4 displays a validation error and continues.
AltSoft Xml2PDF does the same.
FOP CVS HEAD now does the same.

The justifications for both changes are in the commit message. If you
prefer a hard exception in the case of an empty table-body then add a
flag on the user agent for strict vs. relaxed validation testing.

As for removeChild(): Remove that method yourself and try to fix the
layout managers. You'll quickly see that my fix is probably the cleanest
and quickest solution for fixing the problem if we are to allow empty
table-bodies. It removes the trouble maker before it can cause any
problems in the layout engine.

And: As for suggesting a change in the spec. I don't want that. 1. We
have to cope with what we have: XSL 1.0. 2. Empty table-bodies make no
sense but it makes life easier for stylesheet writers not to have to
work around them.

I have nothing more to say about this. I want to spend my time on more
productive things now.

On 24.02.2005 00:01:05 Glen Mazza wrote:
 Jeremias,
 
 This should not be done.  If someone has a problem
 with it--and I've never heard a complaint--they can
 send an email to xsl-editors, for them to adjust the
 content model for fo:table accordingly.  (If they
 don't, they don't.)
 
 Note that the editors are very reasonable about
 this--for example, fo:page-sequence-wrapper and
 fo:wrapper are allowed to have no children for
 programmatic convenience, even though it doesn't make
 sense for these items to be empty.
 
 BTW, what is FONode.removeChild() for anyway?  Why is
 this helpful--we haven't needed such a method for
 years.


Jeremias Maerki



Re: another nose for the grindstone

2005-02-22 Thread Jeremias Maerki

On 22.02.2005 12:43:56 Renaud Richardet wrote:
 Mark, just let me know when you'll start to work on it.
 Clay, sorry for not making clear that i needed the maintenance code
 for reference.
 Jeremias, thanks for the pointer
 
 i'm not sure about the following. please correct me if i'm wrong:
 
 the (currently named) AWTRenderer allows 3 different kinds of output
 1) GUI-application 

or only a single window or just a part of a window.

 2) a java Image (containing all areas represented as Graphics2D's)

Not sure what you mean. Oleg Tkachenko wrote an extension of the AWT
Renderer that paints the area tree to a single bitmap (per page) through
the Graphics2D interface. This is something I like to see integrated
directly into the render.java2d interface.

 3) a printed document through AWTPrintRenderer, or is it 

Right. That's where the Printable interface comes into play.

 the commandline options to start the differents output are

Don't make a 1:1 association between the capabilities of the command
line and all the possible use cases of the Java2D renderer.

 1) -awt

That displays the example preview window in the render.awt.viewer
package.

 2) 

With the bitmap output support added, this will be -jpg and -tiff and
-png etc.

 3) -print

That kicks the AWTPrintRenderer.

 i started to investigate the rendering system. the AbstractRenderer is
 well designed and already implementing a lot of stuff, so that should
 go allright for the AWTRenderer.

Yes, try to use as much as possible from the AbstractRenderer to avoid
duplicate code. If you see possibilities for consolidating functionality
between the PDF and Java2D renderer, then please tell us.

If I don't get any objections by tomorrow morning (CET) I'm going to
rename the AWTRenderer to Java2DRenderer so you can work on the real
thing.

Another thing: If you plan to regularly start to contribute to FOP or
simply to be on the safe side because you're not just going to
contribute a small bugfix only, it might be good if you sent a signed
ICLA (Individual Contributor License Agreement) to the secretary of the
ASF. See here for a text and PDF version of the ICLA:
http://www.apache.org/licenses/#clas
http://www.apache.org/licenses/icla.txt
http://www.apache.org/licenses/icla.pdf

That's not the same as commit rights or committership, but we might get
to that in time. :-)

Jeremias Maerki



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Jeremias Maerki

On 22.02.2005 17:16:56 Glen Mazza wrote:
snip/
 Now, if you want to create a Java2DRenderer as a
 abstract base class for Renderers utilizing
 it--AWTRenderer, AWTPrintRenderer, SVGRenderer,
 TIFFRenderer, etc., that would appear to make a lot
 more sense.  Consider that before you tie
 Java2DRenderer specifically with our AWTRenderer.

Actually, that was what I had in mind but obviously haven't explained
well enough.

 
  AWT is
  actually the windowing toolkit which is something
  that's not used inside
  the renderer. 
 
 True, but PDF is not used within the PDF Renderer. 
 Text codes /0 /0 /a /c etc. etc. are instead.  To a
 degree, using this logic here would then call for us
 renaming PDF Renderer to BinaryOutputCodesRenderer.  

Huh? Lots of dependencies on the PDF package in the PDF renderer.

 
  Only when the Java2D renderer is
  embedded inside a GUI
  application AWT (or rather Swing or SWT) are coming
  into use. 
 
 Yes, so far we have been naming our renderers on the
 final output that the user sees (here, an AWT/Swing
 window), not the internal technology used in
 generating that output.

Not only an AWT/Swing window. We're also printing, creating bitmap
images and we can (via JPS) create PDF and PS files. That's why AWT
doesn't really fit what it does.

  And the
  preview window actually uses Swing, not AWT.
  
 
 But Swing sits on top of AWT, no?  Also, I suspect
 there are AWT-specific packages within the AWTRenderer
 anyway (such as the EventHandlers and EventListeners
 like java.awt.event.ActionEvent).  AWTRenderer appears
 more accurate overall then SwingRenderer, and has the
 added benefit of not sounding as silly.  ;)

:-)


  So here are the proposed changes:
  
  - Package org.apache.fop.render.awt becomes
  org.apache.fop.render.java2d
 
 
 -0.5, because java2d itself uses awt in its package
 name, and we use (or will use) java2d for more than
 the AWTRenderer.  It's more consistent as-is.
 
 Also, AWTRenderer gives the user a better mental
 model of what the output of this type is -- and
 AWT/Swing Window with a document in the middle. 

That's only one use case.

 Java2DRenderer sounds like an intermediate renderer
 that can be output in several different ways, not just
 an AWT window.

EXACTLY That's exactly what is my intention with this proposal.

  - AWTRenderer.java becomes Java2DRenderer.java
  (AWT*.java -
  Java2D*.java)
  
 
 -0.5, because, again, other renderers use or may use
 Java2D.  And we can't all be renaming our renderers
 BinaryOutputCodesRenderer.java and
 Java2DRenderer.java.

I don't buy that.

 Note, of course, these aren't vetoes.

A veto would have been easier. :-) I would simply have stopped and said:
Sigh. Again. Ok, next task.

Would it be more interesting/agreeable if we would leave the render.awt
package and create an AWTRenderer that is optimized for embedding into
AWT/Swing applications? The AWTRenderer would subclass the
Java2DRenderer in the render.java2d package. Improving embeddability of
the AWTRenderer was something I also had in mind. We've had several
instances where people had trouble embedding the AWTRenderer in their
application or simply use the preview form.


Jeremias Maerki



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Jeremias Maerki
Deal. It seems like we want the same things but didn't understand each
other. I hope we do now.

I've documented all this in a Wiki page:
http://wiki.apache.org/xmlgraphics-fop/FopAndJava2D

You said that we name our renderer on the final output the user sees.
So I also added a print and bitmap package to the proposal for
illustration.

I hope that's also what you have in mind. I'm quite happy like this
although the individual packages will be relatively thin. On the other
side, the old AWTRenderer simply did too much in one class for my taste
and at the same time had the wrong name.

The new layout also doesn't require that I prepare the ground for Renaud.
Also, I hope this Wiki page helps him see the direction what we'd like
the thing to go.

Everybody happy?

On 22.02.2005 18:29:41 Glen Mazza wrote:
 WDYT?



Jeremias Maerki



Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Jeremias Maerki
Salut Renaud

I wondered about that, too:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=984481

So far, I can only say that there's so mandatory reason for that change.
It would certainly make the renderers simpler but there might be
problems in other areas. The real downside is when you have to do the
same calculations in every renderer. Some can be (and already are) put
in AbstractRenderer but for others this is not so easily possible. No
definitive answer from me. We'll see what comes out of the page-break
rewrite.


On 22.02.2005 20:28:56 Renaud Richardet wrote:
 bonjour fop-dev's
 
 i've been walking through the rendering process. if i understand it
 rightly, an area doesn't records it's absolute position. therefore, we
 have to pass the currentIPPosition, currentBPPosition all along during
 the rendering process to figure out where to position an area.
 what i don't understand: this information (the absolute position of an
 area) MUST somehow have been known during the building of the area
 tree (otherwise we could'nt know where to break the pages). so my
 question: wouldn't it be easier to record the absolute position of an
 area during the page-breaking process? or am i missing something?
 
 renaud
 
 PS: the abstract Java2DRenderer sounds like a really good deal to me :)



Jeremias Maerki



Re: AWTRenderer: getting the absolute position of an area

2005-02-22 Thread Jeremias Maerki

On 22.02.2005 22:35:15 Renaud Richardet wrote:
snip/
  So far, I can only say that there's so mandatory reason for that change.
  It would certainly make the renderers simpler but there might be
  problems in other areas. The real downside is when you have to do the
  same calculations in every renderer.
 ok, that's what i was affraid of... but i understand that the area
 tree building is already enough complex.
 well, i'll base the Java2DRenderer on the pdf renderer. could someone
 tell me if it's stable enough (especially those tricky issues like
 reference-orientation and writing-mode  that i don't completely
 understand yet).

Well, the PDF Renderer is our reference renderer and it's the only one
that is currently actively maintained. I'll get to the PostScript
renderer later.

Just concentrate on the simple things first. No need to worry about the
writing mode already. The reference orientation is simple. It's just a
matter of getting the transformations right. Run the simple test cases
from the layout engine test suite and work from simple to more
complicated.

snip/


Jeremias Maerki



Re: Renaming the AWT Renderer to Java2D Renderer

2005-02-22 Thread Jeremias Maerki
Given the new layout I don't even need to prepare anything. It would
only complicate things. Just rename the AWTRenderer to Java2DRenderer,
move it to the new location, then create an empty subclass of
Java2DRenderer called AWTRenderer and move any AWT-dependant code to
that subclass.

On 22.02.2005 22:43:01 Renaud Richardet wrote:
 Glen Mazza [EMAIL PROTECTED] wrote:
  Looks good!  Now whether you wish to do this before or
  after Renaud moves the logic over is up to you two.
  There's advantages/disadvantages to either method.
 yes, that looks good! 
 
 Jeremias, if it's ok for the team, i would apreciate if you would do
 the changes asap.
 
 thanks, Renaud



Jeremias Maerki



border-before-width length-conditional

2005-02-21 Thread Jeremias Maerki
Am I right that for a table-cell in collapsing border model the
conditional part of a length-conditional (ex. in border-before-width)
has no effect (i.e. is ignored)?

Thanks,
Jeremias Maerki



Re: border-before-width length-conditional

2005-02-21 Thread Jeremias Maerki
Then, I'm wondering how to handle the conditional part (7.7.9) in this
case because I don't have a clue and it seems not to go well with the
collapsing nature of these borders as well as the rules 1-5 in 6.7.10
for border-collapse=collapse. Also, I don't think the associated edge
is (can be) a leading edge in a reference area from this (table-cell,
table-row, table-body) formatting object. H.

On 21.02.2005 18:11:22 Victor Mote wrote:
 Jeremias Maerki wrote:
 
  Am I right that for a table-cell in collapsing border model 
  the conditional part of a length-conditional (ex. in 
  border-before-width) has no effect (i.e. is ignored)?
 
 That doesn't sound right. I just did a cursory review of the standard and
 can't find any support for that. However, the standard has a way of humbling
 me from time to time, so I may have missed it.
 
 Victor Mote



Jeremias Maerki



Re: border-before-width length-conditional

2005-02-21 Thread Jeremias Maerki
Ah yes, that makes sense. Thanks a lot Vincent. I didn't think about
that.

On 21.02.2005 21:54:19 Vincent Hennebert wrote:
 Jeremias Maerki a écrit :
  Am I right that for a table-cell in collapsing border model the
  conditional part of a length-conditional (ex. in border-before-width)
  has no effect (i.e. is ignored)?
  
 I would answer no, actually not exactly.
 If I understand the spec correctly, the conditional part has an effect only 
 if 
 the generated area begins an ancestor reference area.
 Let's take the example of border-before. If there is a cell before the 
 current 
 cell we don't care about the conditionality: we just have to chose between 
 this 
 border, the border-after of the preceding cell, and the border-after and 
 border-before of the containing table-rows.
 Now if the table has to be broken at the end of a page and the current cell 
 begins a new page (and no border is specified for the table-row), in this 
 case 
 the conditionality has to be taken in consideration. Because the cell would 
 be a 
 leading edge in the normal-flow-reference-area of the page, as defined at the 
 end of section 4.2.5, Stacking Constraints.
 
 Does it answer your question? I may have missed something, I have not 
 carefully 
 studied this aspect of the spec nor the border-collapsing model.
 
 Hope this helps,
 Vincent



Jeremias Maerki



Re: another nose for the grindstone

2005-02-21 Thread Jeremias Maerki
Clay,

he knows that. I told him to use the maintenance branch code as a
reference for bringing back the AWT Renderer in CVS HEAD. Renaud and I
met last Friday at lots.ch.

So, Renaud, please use the code found under the fop-0_20_2-maintain
branch for reference. And happy hacking!

On 22.02.2005 05:38:58 The Web Maestro wrote:
 On Feb 21, 2005, at 4:55 PM, Renaud Richardet wrote:
  bonjour fop-devs
 
 Salut! Bienvenue!
 
  i would like to work on the awt renderer. Mark (or someone else) , are
  you working on it?
  i checked out the code from FOP 0.20.5. is it the latest maintenance 
  version?
 
  thanks, renaud
 
 Actually, the fop-0.20.5 code is merely for reference. All FOP 
 development has moved away from the fop-0.20-5 branch 
 (fop-0_20-maintain OR 'maintenance' branch) in favor of  the re-design 
 branch (HEAD). This was done because the 'maintenance' branch had 
 significant problems that were not easily resolvable. The re-design 
 branch occurred because of problems in implementing the XSL0FO 1.0 
 spec--specifically with the 'keeps' I believe.
 
 In any case, if you wish to contribute to FOP development, please check 
 out the HEAD branch. You may look to fop-0.20.5 for reference, but any 
 work you do on that branch will probably not be integrated into FOP 
 1.0.


Jeremias Maerki



Renaming the AWT Renderer to Java2D Renderer

2005-02-21 Thread Jeremias Maerki
Now that we've got someone who will work on the AWT Renderer I'd like to
know if someone is against renaming the AWT Renderer to Java2D Renderer.
The API in use is actually the Java2D API [1], although most of the
classes had their origin within AWT (and are still in there). AWT is
actually the windowing toolkit which is something that's not used inside
the renderer. Only when the Java2D renderer is embedded inside a GUI
application AWT (or rather Swing or SWT) are coming into use. And the
preview window actually uses Swing, not AWT.

So here are the proposed changes:

- Package org.apache.fop.render.awt becomes org.apache.fop.render.java2d
- AWTRenderer.java becomes Java2DRenderer.java (AWT*.java -
Java2D*.java)

I think the viewer subpackage can stay as is under the renamed package.

Any objections?

[1] http://java.sun.com/j2se/1.4.2/docs/guide/2d/spec.html

Jeremias Maerki



Page breaking

2005-02-20 Thread Jeremias Maerki
I'm at a point now where I run against a wall whatever I look at to do
next. I wanted to put off the page breaking issue as long as possible to
give myself more time to understand all the implications. It turns out
that this wasn't such a bad idea because I got a lot of hints along the
way where I need to pay attention. As you may have seen, my last point
was preparing collapsing borders. The painting works, so the whole
resolution remains. I started with that and realized that the borders
have to be resolved during the layout stage and cannot be resolved
beforehand (see note in 1.3 in [1]). It always comes down to this: I
need to rewrite the page breaking now.

I went back to Simon's and Finn's ideas about page breaking and I see
some overlap. For example, both push top-level BPs to a PageLM. Both
approaches sound good on first read but since this was only the broad
overview of the approach there are obviously some questions popping up,
like:

How does table layout fit in? If you look at the illustration at the
bottom of [1], a BP from a table will most probably need to have
information on what it comprises within each column. Take for example,
the second to last orange line which shows an example BP that comprises
the text line (row 1, cells 3-4), but nothing from columns 1 and 2. Or
rather the RowLM must probably generate some vertical padding for
columns 1 and 2 to fill up the area. BTW, that's where table-cell3a.xml
currently fails.

That smells a lot like there are some additional information items
inside such a BreakPoss/KnuthBox so the addArea stage can later
correctly reproduce what content to generate for a top-level BP. If I'm
thinking about adjusting min/opt/max inside these structures and
handling things like footnotes, floats, collapsing borders and
table-footers, my head starts spinning but that's because I still don't
understand the whole of the Knuth algorithm for example. Thankfully, I
got confirmation yesterday that my copy of Digital Typography is
finally on its way. I should have it by Wednesday.

So this is just my way to tell you guys what I'm doing right now. I'm
going to document everything I find out and appreciate any help here.
And forgive me if right now, I can't keep up with you, yet (But that
should change real quickly now), and if I might seem to have ignored your
earlier input. I didn't. I appreciate it very much and depend on it.

[1] http://wiki.apache.org/xmlgraphics-fop/TableLayout

Thanks,
Jeremias Maerki



Re: Page breaking

2005-02-20 Thread Jeremias Maerki
Right here: http://nagoya.apache.org/eyebrowse/[EMAIL 
PROTECTED]by=threadfrom=984205

On 21.02.2005 01:15:41 Renaud Richardet wrote:
 Jeremias,
 
  I went back to Simon's and Finn's ideas about page breaking and I see
  some overlap. 
 
 could you point me to where Simon and Finn exposed their ideas? 
 thanks, Renaud



Jeremias Maerki



Re: Stray System.out

2005-02-19 Thread Jeremias Maerki
Done.

On 19.02.2005 21:45:28 Thomas DeWeese wrote:
 Hi all,
 
 Can you remove (or comment out) the stray System.out in
 xml-fop/src/java/org/apache/fop/svg/PDFGraphics2D.java:439
 
 Thanks!



Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-16 Thread Jeremias Maerki
Damn, Glen, thanks for being so insistent. I was indeed wrong. You
didn't really give me the prove I needed to be rewired but you got me
looking again all over the spec and I found what was wrong:

It doesn't really matter if the FOs generate reference areas or not, the
key is that 5.3.2 is talking exclusively about block-level FOs. See the
comment within paratheses in the first and second paragraphs in 5.3.2,
for example:

There are two more properties, end-indent and start-indent
(block-level formatting objects) which correspond...

p-s-m and r-b are no block-level FOs. D'Oh! Even though p-s-m and r-b
refer to the 7.10 Common Margin Properties-Block, the properties
space-before|after and start|end-indent only apply to block-level FOs.
Sections 6.4.12 and 6.4.13 explain that the margin-* properties have to
be used to calculate the indents for these the two FOs in question. I
used start|end-indent. :-(

So the 5.3.2 rules cannot be triggered, not because p-s-m and r-b don't
generate reference area, but because they are no block-level FOs!!!

In this light you were right to complain about my bringing in the
block-container example. Still, RenderX is wrong about the
block-container thing. That part still stands. RenderX (and AntennaHouse)
deliberately chose to break inheritance rules in these cases. This is
documented in [1]. But as you say, this is a different story.

[1] http://www.w3.org/2001/08/28-XSL-PR-DOC.html (see comment 20)

Wow, now I need a pause.

Thank you, Glen!

Jeremias Maerki



Re: Markers added to the wrong page

2005-02-15 Thread Jeremias Maerki
Simon, thanks for looking into this. I'm not quite sure I got your 
instructions for a markers5c right. I'd appreciate if you'd check in the 
test case you created.

I've added a Bugzilla item [1] for this. I intend to revisit this later.
It would really be good to have test cases for all those nasty effects.
If you find anything wrong (not just fpr markers) PLEASE write a test
case and check it in even if it doesn't work ATM and you have to add it
to the disabled-testcases.txt. You don't have to write the XPath checks
yourself. We can always do that later.

[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=33555

On 13.02.2005 12:26:27 Simon Pepping wrote:
 Jeremias,
 
 I have looked into the problem in more depth. The wrong retrieved
 marker is not only due to the bogus area, but also to the flawed logic
 of dealing with retrieve-position for the markers in
 PageViewport.addMarkers. Even if block 5 adds a bogus area to page 1,
 block 5 would not qualify for last-ending-within-page.
 
 A correct implementation of the retrieve-position logic requires that
 the traits is-first and is-last are correctly set. These find a place
 in BreakPoss, but not all LMs set the traits correctly. A bogus area
 would again upset the markers, because it would falsely take the trait
 is-first.
 
 If you create markers5c such that block 4 takes two lines (and change
 the region before to: retrieve-position=first-including-carryover),
 you have another failing test case.
 
 BPs for bogus areas can be recognized by their position:
 BP.getPosition().getPosition() == -1. Probably it is a good idea to
 suppress BPs for bogus areas altogether: if (over 
 childBreaks.size() == 0) return null.
 
 Note that for empty blocks also a BP without areas is returned, with
 position = -2. I am not sure whether they make sense. They do not
 generate an area due to a special condition in addAreas. If it is
 possible to add markers to an empty block, such BPs are necessary,
 although the position of the markers around a page break is undefined.
 
 This is a nasty case:
 
 fo:blockfo:block/Several lines of text/fo:block
 
 when the text 'Several...' starts on the new page. There would again
 be an empty area on the previous page. It would again be recognized by
 !BP.generatesAreas(), but it would again falsely take the trait
 is-first.
 
 On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
  Team, 
  
  I've just checked in markers5a and markers5b which look very closely
  which marker is added to which page for every block.
  
  As I'm still somewhat in the process of getting to know the layout
  engine I don't have a quick answer to that although I'm making progress
  in understanding. Here's what I found out so far:
  
  The reason for the bad markers is the addMarkers call, for example in
  BlockLayoutManager.addAreas(). When the LM finds out that the next area
  won't fit on the current page it creates a BreakPoss signalling that
  state. The problem now is that addAreas() also gets these BreakPoss
  instances which aren't visible in the generated document but are still
  generating an (empty) Area (on the page preceeding the one where the
  Area will really come to rest). That causes one marker too many to be
  added to a page.
  
  The same BTW applies to addID() calls which also remembers IDs on the
  wrong pages.
  
  What I'm currently doing is trying to really (!) understand the whole
  BreakPoss mechanism so I can figure out a reliable way to find out how
  to avoid this bug. Two possibilities:
  1. Don't generate bogus areas at all.
  2. Just suppress addMarkers() and addID().
  
  I'm currently wondering if the generated BreakPoss instances should get
  an additional flag (or two) which controls the generation of the area
  and the addMarkers()/addID() calls. addMarkers()/addID() may be
  necessary in certain circumstances while on the other side no area is
  generated (empty block with only markers).
  
  You can easily see these bogus areas when you output to the area tree
  renderer or in build/test-results/layoutengine when running the Ant
  build.
  
  I'll continue investigating but would appreciate any ideas you might
  have.
  
  Jeremias Maerki
  
 
 -- 
 Simon Pepping
 home page: http://www.leverkruid.nl



Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Jeremias Maerki
Hi Luca,

the reason for the effect you're seeing is the inheritance of
start-indent and end-indent. In your exapmle, if you specify a
margin-left and margin-right on the simple-page-master, this results
(corresponding properties) in a start-indent and end-indent of 50pt each.
Now, because start|end-indent are inherited, region-body also starts
with a start-indent and end-indent of 50pt which together with the
parent's start-indent accumulates 100pt because each of the FOs are
generating a reference area. If you'd do this on nested blocks you
wouldn't see this behaviour because they don't establish a new reference
area.

That's really one of the things I stumbled upon and which I believe
after a lot of thinking to be the correct behaviour given by the spec.
RenderX seem to have chosen to break inheritance in these cases because
they create strange effects like you found out now. It took me some time
to get used to it. So in your case you could specify a margin=0pt on
the region-body which triggers the first formula given in 5.3.2. If you
don't specify margin the inherited value for start-indent is used.

There are other instances like on tables where you have to start
specifying start-indent=0pt and end-indent=0pt on table-body if you
have a margin on fo:table.

I'm 99.9% sure that the current behaviour is correct even if it produces
strange results for the XSL-FO user. See my layout engine test cases
where I have such auxiliary margin and start|end-indent properties in
some places.

On 15.02.2005 15:03:00 Luca Furini wrote:
 I noticed a strange behaviour concerning margins that could be related to
 the inheritance of start-indend and end-indent, which was discussed a few
 weeks ago.
 It seems that in some situations the margins are subtracted twice from the
 available inline progression dimension.
 
 In the little fo file I'm attaching there are two simple-page-masters:
 - in one of them, left and right margins are set inside simple-page-master
 itself
 - in the other, they are set inside region-body
 
 In both cases, the page width is 200 points, with left and right margin
 set to 50 points; so, the line width should be 100 points.
 
 In the method PageSequenceLayoutManager.getViewportRectangle(), the
 computed ipd is right when the margins are set in region-body, but it is 0
 if they are set in simple-page-master, because relDims.ipd is already 100
 and start- end-indent are 50.
 
 As this method has not been modified recently, the error (if this
 behaviour is really wrong) must be elsewhere ...
 
 Regards,
 Luca
 
 



Jeremias Maerki



Re: [XML Graphics - FOP Wiki] Updated: CollapsingBorderModel

2005-02-15 Thread Jeremias Maerki
I've documented a few thoughts about the collapsing border model in the
Wiki in preparation for the implementation. There are a few important
decisions that have to be made prior to implementing it, so I'd be glad
for any feedback. 

I'm currently inclined to pursue strategy 1 as it is probably easier to
implement. Fortunately, the painting is a different aspect than the
resolution itself so each can be looked at separately. For strategy 1 I
probably have to add only a single additional flag trait to handle the
border painting for the collapsing model. The flag only indicates which
model is used so the painting code knows how to interpret the border
width.

On 15.02.2005 17:41:27 fop-cvs wrote:
Wiki: XML Graphics - FOP Wiki
Page: CollapsingBorderModel
URL: http://wiki.apache.org/xmlgraphics-fop/CollapsingBorderModel


Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Jeremias Maerki

On 15.02.2005 17:46:54 Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  Hi Luca,
  
  the reason for the effect you're seeing is the
  inheritance of
  start-indent and end-indent. In your exapmle, if you
  specify a
  margin-left and margin-right on the
  simple-page-master, this results
  (corresponding properties) in a start-indent and
  end-indent of 50pt each.
 
 Jeremias,
 
 I think I am missing something here.  Margin-left and
 margin-right are different properties from
 start-indent and end-indent, so I'm unsure why
 inheritance between the two would be applicable in
 this case.
 
 How does specifying margin-left = 50pt result in the
 start-indent value being set to 50pt? 

First rule in 5.3.2 for FOs that generate reference areas:
start-indent = margin-corresponding + padding-corresponding +
border-corresponding-width.

  (Corresponding
 properties just map ***-start to ***-left, etc. for an
 otherwise-same-named property so CP don't appear to be
 relevant to this issue.  Does the spec declare
 margin-left and start-indent to be corresponding
 properties?)

Yes, also in 5.3.2:
There are two more properties, end-indent and start-indent
(block-level formatting objects) which correspond to the various
absolute margin properties.


Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Jeremias Maerki
Yes, I was probably not 100% correct in my explanation though my
interpretation still stands.

On 15.02.2005 18:02:14 Glen Mazza wrote:
 Oh--5.3.2 says: There are two more properties,
 end-indent and start-indent (block-level
 formatting objects) which correspond to the various
 absolute margin properties.
 
 I'm uncertain that that means that they are
 Corresponding Properties however--I wonder if you are
 reading too much into the word correspond.


Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Jeremias Maerki
In mid January Peter helped me understand what's going on. Please have a
look at his explanation [1]. Maybe that makes it clearer. The margin
properties are never used directly in the layout engine (I think and
hope). I'm always working from *-indent and space-*. I think it's
obvious enough from 5.3.2 that *-indent and margin are meant to be 
corresponding,
at least through the rules established therein.

Actually, I think 5.1.2 is the section I should have looked at before
Peter pointed out my mistake. About corresponding properties it says
The simplest example of such properties..., so in my view 5.3.2
describes a complex relationship and so my calling these properties
corresponding was really correct. And the rules in 5.3.2 talk about
corresponding (margin-corresponding), and to what can they correspond
to if not start-indent and end-indent or space-before and space-after
depending on the writing mode?

If you think the current interpretation is wrong, please present your
theory. However, the more I think about this, and the more I'm
explaining, the more I can say that I'm sure that the interpretation is
correct.

[1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgId=2078791

On 15.02.2005 18:27:38 Glen Mazza wrote:
 But if start-indent and margin-left are not
 Corresponding Properties, then the inheritance of
 50pt. you gave in your example would not occur.
 
 IMO, if start-indent and margin-left were actually
 intended to be Corresponding Properties, the former
 would have been named margin-start.  Also,
 margin-before and margin-after (or before-indent and
 after-indent) corresponding properties would also have
 been created.  The description of Corresponding
 Properties, 2nd para of 5.1.2, is unfortunately vague
 about which properties are actually CP's.


Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Jeremias Maerki
90pt, no less.

On 16.02.2005 05:15:36 Glen Mazza wrote:
 On second thought, Jeremias, instead of arguing this,
 why don't we just compromise at 75pt. margins?  ;)



Jeremias Maerki



Re: Error in computation of inline progression dimension ?

2005-02-15 Thread Jeremias Maerki
I'm afraid that you're wrong here. It's true that s-p-m and region-body
don't directly generate reference areas but they also can't, because
they are only used as a template for each new page. For for each page
they serve as FOs that generate reference areas.

But let me give you another example where this is clearer and so you see
that your argument doesn't really count in this discussion. Please open
test/layoutengine/testcases/block-container3.xml. That test case I wrote
specifically to demostrate the effect we're discussing here. You can't
deny that block-container generates a reference area directly. So in
this test case the block inside the b-c has an effective start-indent of
20pt (10pt + 10pt) much like in Luca's example.

If you look at the checks at the end of block-container3.xml you will
realize that there is no 2 (millipoints) anywhere. It's simply the
effect from the reference area which results in the double indent. So if
you wanted to have both text-generating blocks left-aligned at the same
position you'd have to specify start-indent=0pt on the block-container
or on its nested block to reset the start-indent to 0pt.

BTW, I anticipated that I'd have this argument sooner or later. I was
rather baffled when I found out how it is supposed to work. So don't
worry about wasting my time in this case. I simply hope we can then put
it to rest once and for all, ideally documented in a nice Wiki or Web
page, so that if that question comes up again, we can simply point
people to that page.

(additional comments inline)

On 16.02.2005 05:02:30 Glen Mazza wrote:
snip/
  together with the
  parent's start-indent accumulates 100pt because each
  of the FOs are
  generating a reference area. 
 
 I don't think so here--I don't believe either fo:s-p-m
 or fo:region-body generate reference areas--indeed, I
 don't think anything located outside of
 fo:page-sequence does.  The spec says they are *used*
 to create a reference area, but they don't generate
 one themselves.  So maybe your calculations here may
 need changing--because different formulae in 5.3.2
 would hence be activated.
 
 Section 6.1 [1] says There are three kinds of
 formatting objects: (1) those that generate areas, (2)
 those that return areas, but do not generate them, and
 (3) those that are used in the generation of areas.
 
 fo:s-p-m and fo:region-body are type (3), not type
 (1).
 
 fo:s-p-m text:  The fo:simple-page-master formatting
 object generates no area directly. It is used in the
 generation of pages by an fo:page-sequence. type (3)
 
 fo:r-b text:  The fo:region-body formatting object is
 used to generate one region-viewport-area and one
 region-reference-area whenever an
 fo:simple-page-master that has an fo:region-body as a
 child is used to generate a page.  (i.e., type 3)
 
 
 [1]
 http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo-section
 
 
  So in your case you could specify
  a margin=0pt on
  the region-body which triggers the first formula
  given in 5.3.2. 
 
 Again, I don't think so because fo:region-body never
 generates a reference-area.  Hence, with no explicit
 specification of margin properites, the third set of
 formulas then activates:
 
 margin-corresponding = start-indent -
 inherited_value_of(start-indent) -
 padding-corresponding - border-corresponding-width
 
 with the additional rule that:  If the start-indent
 or end-indent properties are not specified their
 inherited value is used in these formulae.
 
 Since start-indent and end-indent were not specified,
 then we have:
 
 margin-corresponding =
 inherited_value_of(start-indent) -
 inherited_value_of(start-indent) -
 padding-corresponding - border-corresponding-width,

This formula is only used to calculate margin-corresponding. It is not
used to calculate the effective indent. Corresponding properties should
not be used directly to do the actual calculations that define the
layout. Ask yourself: How would you decide when to use what property to
calculate the actual indents? That's why the formulas are there to
derive start|end-indent from the corresponding properties. The formula
you're refferring to here is actually used inside IndentPropertyMaker.
It is used to create the margin-corresponding value which is used in
the formula sets 1 and 2.

 or zero for the margin properties on fo:region-body. 
 (i.e., we just rely on the 50pt. on
 simple-page-master.)
 
 So Luca is correct that both fo:simple-page-masters
 should generate the same overall margins of 50 pt.
 each, no?

No. :-)


Jeremias Maerki



Re: testcases

2005-02-12 Thread Jeremias Maerki
Thanks, Simon.

And fop-devs, also note that you are allowed (and encouraged) to correct,
modify, improve and add test cases yourself. :-)

On 12.02.2005 14:25:12 Simon Pepping wrote:
 Jeremias,
 
 Note that you can use the ancestor axis:
 xpath=//text[. = 'line1']/ancestor::pageViewport/@nr 
 instead of 
 xpath=//text[. = 'line1']/../../../../../../../../../@nr


Jeremias Maerki



Re: FOP 0.15 Double Byte Support

2005-02-11 Thread Jeremias Maerki
First of all, please post questions about FOP to the fop-user mailing
list: http://xml.apache.org/fop/maillist.html. This is the development
mailing list. Thanks.

Update your FOP to version 0.20.5. 0.15 is extremely outdated.

As for double byte languages, FOP supports Unicode TrueType fonts, but
it doesn't support different writing modes, yet.

For more information:
- http://xml.apache.org/fop/
- http://xml.apache.org/fop/fonts.html

On 11.02.2005 10:39:23 m r dantuluri wrote:
 Hi,
 
 I am using FOP 0.15 Version. The PDF files rendered by FOP gives junk 
 charecters for double-byte languages like korea, japan etc. 
 
 When I search in the net I found that we need to edit userconfig.xml and 
 needs to write the code to load the xml file using 
 org.apache.fop.apps.Options java file.
 When I searched in my disk, I could not find userconfig.xml, arial.xml (xml 
 files for the fonts).
 We packaged apache related jar files into one jar file. when I look into the 
 jar file I could not find the class file with org.apache.fop.apps.Options and 
 org.apache.fop.configuration.*;
 
 Is FOP 0.15 version supports Double byte languages or not? 
 If supports, what are the steps i need to follow.
 Where can I get more information about FOP 0.15.
 Please help me in finding the solution for this.
 
 Thanks and Regards,
 Raju  



Jeremias Maerki



[VOTE] XML Graphics project charter

2005-02-10 Thread Jeremias Maerki
 code nor 
posted to the subproject mailing lists in 3 months, the PMC chair may e-mail 
the 
committer, the subproject development list, and the PMC mailing list notifying 
the committer that they are going to be moved to inactive status. If there is 
no response in 72 hours, the committer will become inactive, and may be removed 
from the PMC mailing list.

8.6 An inactive status will not prevent a committer committing new code changes 
or posting to the mailing lists. Either of these activities will automatically 
re-activate the committer for the purposes of voting.

9 INFRASTRUCTURE


9.1 The Apache XML Graphics project relies on the Apache XML project and the 
Apache Infrastructure project for the following:

a) Bug Database -- This is a system for tracking bugs and feature requests.

b) Subproject Source Repositories -- These are several repositories containing 
   both the source code and documentation for the subprojects. 

c) Website -- The xmlgraphics.apache.org website will contain information about 
   the Apache XML Graphics project, including documentation, downloads of 
   releases, and this charter. Each subproject will have its own website with 
   subproject information.

d) PMC Mailing List -- This list is for PMC business requiring
   confidentiality, particularly when an individual or company requests
   discretion. All other PMC business should be done on the general
   mailing list.

e) General Mailing List -- This mailing list is open to the public. It is
   intended for discussions that cross subprojects.

f) Subproject Mailing Lists -- Each subproject (except for common components) 
   should have at least one devoted mailing list. Many subprojects may wish to 
   have both user and dev (development) lists. The individual subprojects may 
   decide on the exact structure of their mailing lists.

10 LICENSING


10.1 All contributions to the Apache XML Graphics project adhere to the Apache 
Software Foundation License, v.2.0 
(http://www.apache.org/licenses/LICENSE-2.0). 
All further contributions must be made under the same terms. 

10.2 When a committer is considering integrating a contribution from a 
contributor who has no CLA on file with the Corporation, it is the 
responsibility of the committer, in consultation with the PMC, to conduct due 
diligence on the pedigree of the contribution under consideration; see sections 
7.2 and 7.3.

11 THE DEVELOPMENT PROCESS
==

11.1 The development process is intentionally lightweight; like other Apache 
projects, the committers decide which changes may be committed to the 
repository. Three +1 ('yes' votes) with no -1 ('no' votes or vetoes) are needed 
to approve a significant code change. For efficiency, some code changes from 
some contributors (e.g. feature additions, bug fixes) may be approved in 
advance, in which case they may be committed first and changed as needed, with 
conflicts resolved by majority vote of the committers.

12 SUBPROJECT REQUIREMENTS
==

12.1 Each subproject should have a set of requirements as well as an up-to-date 
release plan and design document on its dedicated web page.

12.2 It is recommended that each subproject have a smoke-test system that works 
at least as a basic integration test.

13 RELATIONSHIP TO OTHER APACHE PROJECTS


13.1 The Apache XML Graphics project should work closely with other Apache 
projects, such as XML, Jakarta and the Apache Server, to avoid redundancy and 
achieve a coherent architecture among Apache XML Graphics and these projects.


*

Jeremias Maerki



[ANN] New mailing lists for the Apache XML Graphics project

2005-02-10 Thread Jeremias Maerki
Finally, we got the rest of our requested mailing lists, thanks to Roy T.
Fielding.

Please all FOP and Batik committers, subscribe to
[EMAIL PROTECTED] by sending an empty mail to
[EMAIL PROTECTED]

This mailing list is used to for:
- discussing anything related to the XML Graphics project as a whole,
i.e. not related to one of FOP or Batik in particular.
- discussing anything about common components once we have the
infrastructure to even think about it.

Only confidential stuff should be discussed on the PMC list, any PMC
discussion that doesn't need confidentiality should got to
[EMAIL PROTECTED] from now on.

I hope this will avoid too much annoying cross-posting in the future
(just what I do right now).

There's also another mailing list, [EMAIL PROTECTED] which
will receive all changes coming from the XML Graphics Wiki (I will
change that shortly now that I have apsite powers. ATM the commits are
going to FOP. The commits list will also receive changes made in the new
SVN repository for the XML Graphics website which I hope will also soon
be created. Please subscribe by sending an empty mail to
[EMAIL PROTECTED]


Jeremias Maerki



page breaks (was: Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking4.xml)

2005-02-10 Thread Jeremias Maerki
I think it should be relatively simple to rearrange PSLM to set up the
right page before the call to getNextBreakPoss(). What I'm wondering,
though, is why the breaks are handled during getParentArea using
information in Traits on areas and not through BreakPoss instances
during getNextBreakPoss() stage. Does anyone know? There are no such
traits described in the spec that I could find in a quick fly-over. And
IMO it doesn't make sense to do it this way. What am I missing?

On 10.02.2005 14:28:45 Jeremias Maerki wrote:
 Ouch! The PageSequenceLayoutManager has a big problem. It sets the
 reference IPD for the flow once at the beginning and then no more.
 Subsequent pages get their (correct) page master only during addArea
 stage through getParentArea(). But the flow reference area has to be set
 prior to doing any getNextBreakPoss() on a new page. So it's not
 resetPosition() methods that don't behave as I claimed in my earlier CVS
 message (although I found a few strange things with resetPosition() while
 looking at table headers/footers).
 
 On 10.02.2005 13:52:35 jeremias wrote:
  jeremias2005/02/10 04:52:35
  
Modified:test/layoutengine/testcases normal-breaking4.xml
Log:
Adding an additional block at the end to see if a new block would behave 
  differently.


Jeremias Maerki



Re: cvs commit: xml-fop/test/layoutengine/testcases table-cell5a.xml

2005-02-09 Thread Jeremias Maerki
Uhm, don't look too closely at my latest test cases. I've made some
mistake in interpretation. Revisiting now...


Jeremias Maerki



Re: Problems with layoutengine test files

2005-02-09 Thread Jeremias Maerki
Corrected. Thanks, Simon.

On 09.02.2005 22:08:20 Simon Pepping wrote:
 Jeremias,
 
 On Mon, Feb 07, 2005 at 10:29:10AM +0100, Jeremias Maerki wrote:
  Simon,
  
  can you tell me which parser and XSLT processor combination gave you
  these problems? I'd like to reproduce the problem so I can be sure I fix
  them correctly. Thanks.
 
 Sun's SDK 1.4.2, crimson and Xalan Java 2.5.2: error
 endorsed dirs: Xerces-J 2.4.0, Xalan Java 2.5.2: succes
 endorsed dirs, FOP's libraries: Xerces-J 2.2.1,  Xalan Java 2.4.1:
 error
 
 Error: There was 1 error:
 1) 
 text-decoration1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1)java.lang.RuntimeException:
  Expected XPath expression to evaluate to 'line-through', but got 'li' 
 (XPath: //flow/block[3]/lineArea/inlineparent[1]/text)


Jeremias Maerki



FOP at ApacheCon Europe 2005?

2005-02-08 Thread Jeremias Maerki
Most of you will probably have heard that ApacheCon Europe will be happening in
July. I think it would be great if FOP would somehow be visible there.
There's a call for participation ending 2005-03-04. Any ideas?

Who's planning to go to Stuttgart? I won't miss it! It would be cool to
meet some of you there, especially those I haven't met personally or on
the phone yet. Also, it might be a great opportunity for a little
hackathon.

Jeremias Maerki



Re: Markers added to the wrong page

2005-02-07 Thread Jeremias Maerki
Simon,

I'm sorry that I missed your plan. I didn't remember your posting this.

I think your plan would be a good start into refactoring the breaking in
block progression direction. I think it'll need to be clarified WRT
resets/backtracking in case of final decisions on page break, column
handling and intrusion. Your approach seems to create BPs in advance of
which some might be discarded because of later decisions. These will
then be rebuilt based on different circumstances.

I'm somewhat torn between a project plan I have to follow and doing
things right the first time. So I'll apply my changes for now and I'll
keep the whole thing on my todo list with a big exclamation mark. It
could very well be that because of my next tasks (tables and keeps) I
will get back to this sooner rather than later. Another aspect here: I'd
like to have some well visible improvements to the code quickly so it
shows to the outside that the project's not dead like many users think.

We'll see what happens. Thanks for your input and I hope you'll find
some time soon to do some coding yourself.

On 06.02.2005 22:08:40 Simon Pepping wrote:
 Jeremias,
 
 I do not have much time to look into your problem, so I will just try
 to give a quick answer.
 
 In my view the current BP setup is not able to generate good page
 break decisions. It only can do a first-fit algorithm. From your
 account, BPs are also overloaded to signal the completion of a page
 while they do not really end an area. Your hack is a hack indeed, but
 from a quick inspection I would say that it properly marks the
 overloaded nature of BPs.
 
 I have written down a proposal for a different strategy of page break
 decision. I put my description on the wiki,
 http://wiki.apache.org/xmlgraphics-fop/PageLayout. I believe it serves
 two goals:
 1. Enabling smarter page break algorithms.
 2. Simplifying the addAreas calls, and esp. its iteration over the
 collected BPs.
 
 I have not had time to implement this, and therefore also no time to
 detect the flaws in my proposal. I would not mind if someone else
 would implement it.
 
 Regards, Simon
 
 On Thu, Feb 03, 2005 at 06:19:29PM +0100, Jeremias Maerki wrote:
  Team, 
  
  I've just checked in markers5a and markers5b which look very closely
  which marker is added to which page for every block.
  
  As I'm still somewhat in the process of getting to know the layout
  engine I don't have a quick answer to that although I'm making progress
  in understanding. Here's what I found out so far:
  
  The reason for the bad markers is the addMarkers call, for example in
  BlockLayoutManager.addAreas(). When the LM finds out that the next area
  won't fit on the current page it creates a BreakPoss signalling that
  state. The problem now is that addAreas() also gets these BreakPoss
  instances which aren't visible in the generated document but are still
  generating an (empty) Area (on the page preceeding the one where the
  Area will really come to rest). That causes one marker too many to be
  added to a page.
  
  The same BTW applies to addID() calls which also remembers IDs on the
  wrong pages.
  
  What I'm currently doing is trying to really (!) understand the whole
  BreakPoss mechanism so I can figure out a reliable way to find out how
  to avoid this bug. Two possibilities:
  1. Don't generate bogus areas at all.
  2. Just suppress addMarkers() and addID().
  
  I'm currently wondering if the generated BreakPoss instances should get
  an additional flag (or two) which controls the generation of the area
  and the addMarkers()/addID() calls. addMarkers()/addID() may be
  necessary in certain circumstances while on the other side no area is
  generated (empty block with only markers).
  
  You can easily see these bogus areas when you output to the area tree
  renderer or in build/test-results/layoutengine when running the Ant
  build.
  
  I'll continue investigating but would appreciate any ideas you might
  have.
  
  Jeremias Maerki
  
 
 -- 
 Simon Pepping
 home page: http://www.leverkruid.nl



Jeremias Maerki



Re: Problems with layoutengine test files

2005-02-07 Thread Jeremias Maerki
Simon,

can you tell me which parser and XSLT processor combination gave you
these problems? I'd like to reproduce the problem so I can be sure I fix
them correctly. Thanks.

On 06.02.2005 13:54:54 Simon Pepping wrote:
 Hi Jeremias,
 
 I have errors with the layoutengine test files, for example:
 
 text-decoration1.xml(org.apache.fop.layoutengine.LayoutEngineTestSuite$1)java.lang.RuntimeException:
 Expected XPath expression to evaluate to 'line-through', but got 'li'
 (XPath: //flow/block[3]/lineArea/inlineparent[1]/text)
 
 This is due to the fact that the text may be split over more than one
 text area. Indeed, whether I get the error depends on which parser
 version I use; different parsers may produce different arrangements of
 text over text areas.
 
 If you change the test to:
 
 eval expected=line-through 
 xpath=//flow/block[3]/lineArea/inlineparent[1]/
 
 the error disappears. I think XObject.str() applies the XPath string
 function, which returns the string-value of the first node. If you
 evaluate the parent node 'inlineparent', you get the string-value of
 all of its children, which is usually what you want to have.
 
 There are many such cases in the test files. I think you should modify
 all cases where you test on the content of a text area.


Jeremias Maerki



Re: Markers added to the wrong page

2005-02-06 Thread Jeremias Maerki
Glen,

no, I'm afraid the isBogus() method is necessary because it checks the
parent LM. In the markers6a.xml example (for which I still have to write
the checks, I just found out), the block in the third cell of the fifth
row has an effective BPD of 0 and therefore fits nicely into the
available stacking dimension. Therefore its BreakPoss doesn't have the
nextBreakOverflows() return true. But the row in which that block and
its parent cell are found has an overflow because of the first two cells
which don't fit. If isBogus() doesn't check the parentLM the markers for
row 5 are added to page 1 which is wrong.

I think I'll commit my patch as is tomorrow. This will solve the problem
for now, but I have a feeling that I might have to do some additional
work on the BreakPoss part quite soon when I get to tasks such as keeps
which is quite soon now. The isBogus() method is easily removed if it
turns up later that it can be handled differently and in a better way.

On 06.02.2005 04:43:48 Glen Mazza wrote:
 Jeremias,
 
 I don't see the need for the bBogus variable/isBogus()
 method, because in the three or four places where the
 value of this variable is actually *being used*, it is
 just set to :
 
 bBogus = !bp1.generatesAreas(); 
 
 So it appears you can just rely on
 !bp1.generatesAreas() in these places
 instead--perhaps just commenting the conditional that
 bogus areas are being ignored--and we can worry about
 getting rid of the actual bogus areas later (when
 overall team grokkage in this part of the code
 improves).
 
 Glen
 
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  I've got a possible fix for the problem. But I don't
  know if it's not
  too much of a hack. At least it somehow feels like a
  hack. Any comments
  about the attached patch? Obviously, some javadocs
  are missing and the
  naming could probably be improved but this is just
  an idea how this
  could be fixed.
  
  IMO it would be nicer if these bogus areas as I
  call them wouldn't be
  constructed at all. I experimented with such an
  approach but the code
  got far too complicated with too much
  copy/paste/modify. And I also
  didn't manage to make it work. On the other side
  these special areas
  are not a big problem since there are relatively few
  of them.
  
  Still interested in opinions and ideas Thanks!
  



Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/area AreaTreeHandler.java

2005-02-05 Thread Jeremias Maerki
Glen,

no, that's ok. Thanks for the review. I've removed my change locally and
will commit either tomorrow or on Monday. I can't commit right now
because it overlaps with my changes for the marker problem where I still
hope for another comment.

On 05.02.2005 04:11:10 Glen Mazza wrote:
 Jeremias,
 
 We are using this pageCount statistic only at
 endDocument() in ATH, i.e., when the document is
 complete.  Any problem with us just relying on the
 rootFObj.getRunningPageNumberCounter() in
 endDocument() instead of this page-by-page callback
 (i.e., get rid of pageCount in ATH)?  I would like to
 keep things as simple as possible in ATH and PSLM.
 
 Thanks,
 Glen  
 
 --- [EMAIL PROTECTED] wrote:
 
  jeremias2005/02/03 12:44:45
  
Modified:src/java/org/apache/fop/area
  AreaTreeHandler.java
Log:
Add a facility for the PageSequenceLayoutManager
  to notify about a new page being added so the
  rendering statistics work again.




Jeremias Maerki



Start using *-position traits?

2005-02-04 Thread Jeremias Maerki
Team,

Chapter 4.2.2 Common Traits defines four traits (top-position,
bottom-position, left-position, right-position) which describes the
placement of areas within the nearest ancestor reference-area (or the
page-viewport-area). We don't use these trait but recreate the placement
of individual areas in the renderer (actually and effectively in each 
(!) renderer). I wondered a few times during the last month if we should
have the layout manager handle the calculation of the coordinates. This
has a few advantages:
- All layout is really in the layout managers.
- Each renderer really only paints the areas in the place it is told to.

The obvious disadvantage is the effort needed to write the code that
generates these traits in all layout managers.

The reason I'm bringing this up now is my attempt to implement table row
backgrounds where I don't manage to place the background areas in the
right places due to placement logic in the renderer(s). Of course, there
are work-arounds and I only have to fix AbstractRenderer in this case
but it doesn't feel right. There's already enough placement logic in the
PDFRenderer which needs to be duplicated in all other renderers. I can
also remember the synchronization effort when I wrote the original
PSRenderer.

I think it would also simplify the renderers itself, making it easier to
develop a new one, if we started using left-position and top-position
traits. The other two may be necessary as soon as there's more effort
towards implementing writing-modes.

Keiron responded to a similar question in 2002:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=214823

I don't share his opinion on point 3 because whenever we have a change
in reference-orientation we also have a new reference-area which
establishes a new coordinate system. So I don't think it will be
complicated to calculate the right coordinates. But I may be wrong.

Opinions?

Jeremias Maerki



Re: Start using *-position traits?

2005-02-04 Thread Jeremias Maerki
Well, this might have been a bit premature. The change necessary
actually fixed a bug in AbstractRenderer, but still it might be worth
discussing the point.

On 04.02.2005 15:51:58 Jeremias Maerki wrote:
 Team,
 
 Chapter 4.2.2 Common Traits defines four traits (top-position,
 bottom-position, left-position, right-position) which describes the
 placement of areas within the nearest ancestor reference-area (or the
 page-viewport-area). We don't use these trait but recreate the placement
 of individual areas in the renderer (actually and effectively in each 
 (!) renderer). I wondered a few times during the last month if we should
 have the layout manager handle the calculation of the coordinates. This
 has a few advantages:
 - All layout is really in the layout managers.
 - Each renderer really only paints the areas in the place it is told to.
 
 The obvious disadvantage is the effort needed to write the code that
 generates these traits in all layout managers.
 
 The reason I'm bringing this up now is my attempt to implement table row
 backgrounds where I don't manage to place the background areas in the
 right places due to placement logic in the renderer(s). Of course, there
 are work-arounds and I only have to fix AbstractRenderer in this case
 but it doesn't feel right. There's already enough placement logic in the
 PDFRenderer which needs to be duplicated in all other renderers. I can
 also remember the synchronization effort when I wrote the original
 PSRenderer.
 
 I think it would also simplify the renderers itself, making it easier to
 develop a new one, if we started using left-position and top-position
 traits. The other two may be necessary as soon as there's more effort
 towards implementing writing-modes.
 
 Keiron responded to a similar question in 2002:
 http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=214823
 
 I don't share his opinion on point 3 because whenever we have a change
 in reference-orientation we also have a new reference-area which
 establishes a new coordinate system. So I don't think it will be
 complicated to calculate the right coordinates. But I may be wrong.
 
 Opinions?


Jeremias Maerki



Re: Start using *-position traits?

2005-02-04 Thread Jeremias Maerki
Thanks for sharing your thoughts, Victor. For the moment I've got my
issue solved but as I already said, it may be beneficial to reconsider
the approach here. I'll wait and see what the others have to say about
it.

You popping up again reminds me that I still have an issue on my task
list: Making an integration of Foray into my JAFOP thingy. I'm quite
interested in comparing FOP 1.0dev with other implementations as I go.
Gotta find some time...

On 04.02.2005 18:04:24 Victor Mote wrote:
 Jeremias Maerki wrote:
 
  Chapter 4.2.2 Common Traits defines four traits 
  (top-position, bottom-position, left-position, 
  right-position) which describes the placement of areas within 
  the nearest ancestor reference-area (or the 
  page-viewport-area). We don't use these trait but recreate 
  the placement of individual areas in the renderer (actually 
  and effectively in each
  (!) renderer). I wondered a few times during the last month 
  if we should have the layout manager handle the calculation 
  of the coordinates. This has a few advantages:
  - All layout is really in the layout managers.
  - Each renderer really only paints the areas in the place it 
  is told to.
  
  The obvious disadvantage is the effort needed to write the 
  code that generates these traits in all layout managers.
  
  The reason I'm bringing this up now is my attempt to 
  implement table row backgrounds where I don't manage to place 
  the background areas in the right places due to placement 
  logic in the renderer(s). Of course, there are work-arounds 
  and I only have to fix AbstractRenderer in this case but it 
  doesn't feel right. There's already enough placement logic in 
  the PDFRenderer which needs to be duplicated in all other 
  renderers. I can also remember the synchronization effort 
  when I wrote the original PSRenderer.
  
  I think it would also simplify the renderers itself, making 
  it easier to develop a new one, if we started using 
  left-position and top-position traits. The other two may be 
  necessary as soon as there's more effort towards implementing 
  writing-modes.
  
  Keiron responded to a similar question in 2002:
  http://nagoya.apache.org/eyebrowse/BrowseList?listName=fop-dev
 @xml.apache.orgby=threadfrom=214823
  
  I don't share his opinion on point 3 because whenever we have 
  a change in reference-orientation we also have a new 
  reference-area which establishes a new coordinate system. So 
  I don't think it will be complicated to calculate the right 
  coordinates. But I may be wrong.
  
  Opinions?
 
 Hi Jeremias:
 
 It is fascinating to me how many times you and I happen to be working on
 exactly the same issue, as we are right now. FWIW, the FOray approach is as
 follows: Areas do not store any location information at all. The only size
 information stored is a progressionDimension value and a value for the
 resolved anteriorSpace. This is enough information, however, for each Area
 to compute and return to the Renderer where it should be rendered. Every
 Area either is or has an ancestor area that knows intrinsically what its
 location is just from its properties. Every Area knows its own IPD and BPD.
 So by considering the progressionDimension and anteriorSpace (the resolved
 value of space-before/after or space-start/end) of other Areas already
 stacked in the containing Area, any Area knows its location.
 
 Keiron is right that the computations are tricky for changes in
 reference-orientation and writing-mode, but I think dealing with them in the
 Area tree once is much easier than any other approach I can imagine. My code
 currently has the various writing-modes handled correctly (I think), but
 doesn't yet deal with changes in writing-mode or reference-orientation. The
 main reason I haven't tackled that yet is that I am still trying to decide
 how much of that work belongs in Area Tree and how much needs to be
 considered Renderer-specific. 
 
 With this scheme, Layout never has to worry about location, orientation, or
 writing-mode, only sizes (IPD and BPD). Renderers don't have to compute any
 of them either, they just ask each Area where it wants to be rendered.
 
 In short, I think you are very much on the right track here. One caveat: I
 don't have all of my stuff working yet, so there may be a gotcha that I
 haven't thought of.
 
 If these comments are not helpful, please let me know. I don't mean to
 generate noise -- I just like to support good ideas when I see them.
 
 Victor Mote



Jeremias Maerki



Markers added to the wrong page

2005-02-03 Thread Jeremias Maerki
Team, 

I've just checked in markers5a and markers5b which look very closely
which marker is added to which page for every block.

As I'm still somewhat in the process of getting to know the layout
engine I don't have a quick answer to that although I'm making progress
in understanding. Here's what I found out so far:

The reason for the bad markers is the addMarkers call, for example in
BlockLayoutManager.addAreas(). When the LM finds out that the next area
won't fit on the current page it creates a BreakPoss signalling that
state. The problem now is that addAreas() also gets these BreakPoss
instances which aren't visible in the generated document but are still
generating an (empty) Area (on the page preceeding the one where the
Area will really come to rest). That causes one marker too many to be
added to a page.

The same BTW applies to addID() calls which also remembers IDs on the
wrong pages.

What I'm currently doing is trying to really (!) understand the whole
BreakPoss mechanism so I can figure out a reliable way to find out how
to avoid this bug. Two possibilities:
1. Don't generate bogus areas at all.
2. Just suppress addMarkers() and addID().

I'm currently wondering if the generated BreakPoss instances should get
an additional flag (or two) which controls the generation of the area
and the addMarkers()/addID() calls. addMarkers()/addID() may be
necessary in certain circumstances while on the other side no area is
generated (empty block with only markers).

You can easily see these bogus areas when you output to the area tree
renderer or in build/test-results/layoutengine when running the Ant
build.

I'll continue investigating but would appreciate any ideas you might
have.

Jeremias Maerki



Re: Markers added to the wrong page

2005-02-03 Thread Jeremias Maerki
I've got a possible fix for the problem. But I don't know if it's not
too much of a hack. At least it somehow feels like a hack. Any comments
about the attached patch? Obviously, some javadocs are missing and the
naming could probably be improved but this is just an idea how this
could be fixed.

IMO it would be nicer if these bogus areas as I call them wouldn't be
constructed at all. I experimented with such an approach but the code
got far too complicated with too much copy/paste/modify. And I also
didn't manage to make it work. On the other side these special areas
are not a big problem since there are relatively few of them.

Still interested in opinions and ideas Thanks!


On 03.02.2005 18:19:29 Jeremias Maerki wrote:
 Team, 
 
 I've just checked in markers5a and markers5b which look very closely
 which marker is added to which page for every block.
 
 As I'm still somewhat in the process of getting to know the layout
 engine I don't have a quick answer to that although I'm making progress
 in understanding. Here's what I found out so far:
 
 The reason for the bad markers is the addMarkers call, for example in
 BlockLayoutManager.addAreas(). When the LM finds out that the next area
 won't fit on the current page it creates a BreakPoss signalling that
 state. The problem now is that addAreas() also gets these BreakPoss
 instances which aren't visible in the generated document but are still
 generating an (empty) Area (on the page preceeding the one where the
 Area will really come to rest). That causes one marker too many to be
 added to a page.
 
 The same BTW applies to addID() calls which also remembers IDs on the
 wrong pages.
 
 What I'm currently doing is trying to really (!) understand the whole
 BreakPoss mechanism so I can figure out a reliable way to find out how
 to avoid this bug. Two possibilities:
 1. Don't generate bogus areas at all.
 2. Just suppress addMarkers() and addID().
 
 I'm currently wondering if the generated BreakPoss instances should get
 an additional flag (or two) which controls the generation of the area
 and the addMarkers()/addID() calls. addMarkers()/addID() may be
 necessary in certain circumstances while on the other side no area is
 generated (empty block with only markers).
 
 You can easily see these bogus areas when you output to the area tree
 renderer or in build/test-results/layoutengine when running the Ant
 build.
 
 I'll continue investigating but would appreciate any ideas you might
 have.
 
 Jeremias Maerki



Jeremias Maerki


MarkerFixProposal.diff.txt
Description: Binary data


Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-02 Thread Jeremias Maerki
No, it don't think so. That bug happens in getNextBreakPoss() while mine
happens in addAdreas().

On 02.02.2005 10:36:41 Chris Bowditch wrote:
 Jeremias Maerki wrote:
  Just to be clear. This ArrayOutOfBoundsException is not the same problem
  I've described in my earlier post. I just happened to run into both
  problems at the same time. Running normal-breaking2.xml with the current
  code (without my patch) will result in a document with 1 page and the
  linefeeds displayed as #. So, this test will fail because of the
  single check in the test case.
  
  If someone has an idea about the ArrayOutOfBoundsException, all the
  better. I'm currently trying to debug that thing.
 
 Jeremias: Have you seen the following bug which appears to be the same 
 problem?
 
 http://issues.apache.org/bugzilla/show_bug.cgi?id=32174
 
 snip/
 
 Chris



Jeremias Maerki



Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-02 Thread Jeremias Maerki
Thanks a lot, Luca. That was it. I was slowly tracking that thing down.
I knew already that these start indices were wrong but hadn't figured
out how to fix it.

And thanks to Chris for the pointers earlier.

In the meantime I got to know a lot about the inner workings of the line
layout. :-) Good for the next time.

On 02.02.2005 15:24:44 Luca Furini wrote:
 
 Jeremias Maerki wrote:
 
  If someone has an idea about the ArrayOutOfBoundsException, all the
  better. I'm currently trying to debug that thing.
 
 It's because of this line in LineLM.addAreas():
 iCurrParIndex = 0;
 If a block has properly handled preserved linefeeds, it will generate more
 than one paragraph, so the ArrayList knuthParagraphs will have more than one
 element.
 In your test file, there will be:
 (Paragraph #0) !-- list level 1 --
 (Paragraph #1) fo:list-block provisional-distance-between-starts=0.4cm
 (Paragraph #2)provisional-label-separation=0.15cm
 (Paragraph #3) !-- list item --
 
 If the block is split between two pages, the method LineLM.addAreas will be
 called twice: for example, there will be Paragraph #0 and #1 on page 1, and
 the others on page 2.
 The second time addAreas() is called iCurrParIndex is set to 0, and here is
 the bug, because the index stored in the LineBreakPosition lbp refers to an
 element in Paragraph #2!
 
 Maybe the best place to store the correct value is inside the
 LineBreakPositions; I'm attaching a little patch which modifies the
 LineBreakPosition class (and also removes an old, unused method).
 
 As per the ignored newline characters in the TextLM, I really can't remember
 why I wrote those lines! :-)
 It really looks like they shouldn't be ignored.
 
 HTH
 Regards,
 Luca
 



Jeremias Maerki



Re: Dual Column Layout

2005-02-02 Thread Jeremias Maerki
It's going to be rewritten from scratch because the layout code is all
new. Just don't ask when this is going to happen. :-) We would be glad
to accept any help. It could speed up the process.

On 02.02.2005 22:53:20 Puppala, Kumar (LNG-DAY) wrote:
 Is the algorithm for column-balancing
 going to be change in the next release to make it work more accurately? 


Jeremias Maerki



Problem with newlines in TextLayoutManager

2005-02-01 Thread Jeremias Maerki
Luca (and maybe Finn),

I think I found a problem with TextLayoutManager where NEWLINEs are not
properly handled. Consider the following block (extracted from list.fo):

  fo:block line-height=10pt space-before.optimum=5cm 
white-space-collapse=false white-space-treatment=preserve 
linefeed-treatment=preserve wrap-option=no-wrap
![CDATA[!-- list level 1 --
fo:list-block provisional-distance-between-starts=0.4cm
   provisional-label-separation=0.15cm

  !-- list item --
]]
/fo:block

If the FO file is parsed directly the SAX events happen to always start
with a NEWLINE and then adding exactly one line of text. In this case
the current algorithm finds the NEWLINE characters and adds the
necessary KnuthPenalty.

However, if you do an XSLT transform (as happens with my layout engine
test cases) the SAX characters() call can contain more than one line at
once. In this case the algorithm ignores the NEWLINEs (see comment). I
wonder why this was done like this. I think the whole linefeed handling
is done beforehand and all NEWLINEs still coming through this algorithm
are preserved linefeeds.

Is there some reason why my patch below would make anything worse? It
seems to fix my problem here and all my test cases still pass (at least
the ones that passed before).

Thanks for any feedback!


Index: TextLayoutManager.java
===
RCS file: 
/home/cvs/xml-fop/src/java/org/apache/fop/layoutmgr/TextLayoutManager.java,v
retrieving revision 1.29
diff -u -r1.29 TextLayoutManager.java
--- TextLayoutManager.java  25 Jan 2005 10:55:47 -  1.29
+++ TextLayoutManager.java  1 Feb 2005 21:33:07 -
@@ -788,16 +788,13 @@
 iThisStart = iNextStart;
 iTempStart = iNextStart;
 MinOptMax wordIPD = new MinOptMax(0);
-for (;
- iTempStart  textArray.length
-  textArray[iTempStart] != SPACE
-  textArray[iTempStart] != NBSPACE;
- iTempStart ++) {
-// ignore newline characters
-if (textArray[iTempStart] != NEWLINE) {
-wordIPD.add
-(new 
MinOptMax(fs.getCharWidth(textArray[iTempStart])));
-}
+for (; iTempStart  textArray.length
+ textArray[iTempStart] != SPACE
+ textArray[iTempStart] != NBSPACE
+ textArray[iTempStart] != NEWLINE;
+iTempStart++) {
+wordIPD.add(
+new MinOptMax(fs.getCharWidth(textArray[iTempStart])));
 }
 wordIPD.add(MinOptMax.multiply(letterSpaceIPD, (iTempStart - 
iThisStart - 1)));
 vecAreaInfo.add


Jeremias Maerki



Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking2.xml

2005-02-01 Thread Jeremias Maerki
Just to be clear. This ArrayOutOfBoundsException is not the same problem
I've described in my earlier post. I just happened to run into both
problems at the same time. Running normal-breaking2.xml with the current
code (without my patch) will result in a document with 1 page and the
linefeeds displayed as #. So, this test will fail because of the
single check in the test case.

If someone has an idea about the ArrayOutOfBoundsException, all the
better. I'm currently trying to debug that thing.

On 01.02.2005 22:51:38 jeremias wrote:
 jeremias2005/02/01 13:51:37
 
   Modified:test/layoutengine disabled-testcases.txt
   Added:   test/layoutengine/testcases normal-breaking2.xml
   Log:
   Regression test for ArrayOutOfBoundsException in 
 LineLayoutManager.addAreas() (to be fixed).


Jeremias Maerki



Re: Start Using FOP

2005-01-31 Thread Jeremias Maerki
There's lots of documentation on our website. Start here:
http://xml.apache.org/fop/running.html

Also check our resources section which contains links to online
tutorials and articles:
http://xml.apache.org/fop/resources.html#documents-xslfo

If you're getting stuck somewhere please send questions to the fop-user
mailing list, not to this list which is dedicated to the development of
FOP. Thanks.

On 31.01.2005 09:48:06 jeb501 wrote:
 Anybody there to help me to get start with FOP



Jeremias Maerki



Re: Background images

2005-01-30 Thread Jeremias Maerki
I didn't so much look which FOs needed background images but didn't
support them. It was rather about implementing the various properties
and the rendering part. It may still be that some FOs are not yet
properly connected (through TraitSetter) to generate background images
but if there are any they will surely come up sooner or later.

On 31.01.2005 00:15:19 Glen Mazza wrote:
 Pardon me, forgot to ask:  where did the background images need to be 
 implemented (i.e., which FO's needed them that the spec doesn't support)?


Jeremias Maerki



Re: block-containers with BPD set

2005-01-27 Thread Jeremias Maerki
Thanks to Victor and Andreas for helping me here, although I'm still
confused.

On 27.01.2005 00:25:27 Victor Mote wrote:
 Andreas L. Delmelle wrote:
 
  Do you feel the contents of the block-container should not be 
  broken up at all? (Hence the analogy to a fo:external-graphic?)
 
 No, sorry, I didn't mean to imply that. I think the contents can (possibly,
 depending on the overflow constraints) be broken up, but that the viewport
 cannot be. So the analogy with external-graphic breaks down there. The
 similarity is in the fact that they (in this case) have a fixed size and
 must move in their entirety.

This seems to be contradicting. I don't see how the overflow property
would control such behaviour. Also, if you say that they must move in
their entiretly, how can the contents be broken up? Or does they
refer to something else than the contents?

snip/

  (more or less the effect the page-height property has on the 
  page-viewport-areas generated during formatting) In that 
  case, is it even conceivable to have more than one 
  viewport-area for a block-container with constrained bpd?
 
 Yes. This seems most useful to me in cases where the viewport would occupy
 most or all of the main-reference-area, as in the case of the
 report-turned-sideways example I gave earlier. Suppose you have some unknown
 quantity of 132-column output you want to show in landscape mode. You can
 create a fixed-size block-container, tell it to overflow into other ones,
 add a break constraint at the end of each page, and you now get n pages of
 output.

Well, this is a case where I'd rather use a separate page-sequence with the
reference orientation set on the simple-page-master.

  Or would it mean that _all_ of them taken together should be 
  _that_ big?
 
 The previously-cited 1.1 item seems to indicate that the constraint applies
 to each of the viewport areas individually as opposed to all of them in
 total. However, I could misunderstand.
 
  Having no constraints on the keeps, and only the bpd 
  specified, it seems perfectly legal to break and interpret 
  the bpd constraint as a total that may be divided over 
  multiple viewport areas, but it may seem a bit tricky.
 
 You may be right, but I can't think of a case where that would be useful.
 
 AFAICT, keeps and space constraints would be left intact for the contents of
 the block-container. So, if a decision has been made that an additional
 viewport is needed to fit the contents, the keeps, breaks, and spaces would
 be used to decide which content went to an anterior vp and which to a
 posterior vp, just like in any page-break decision.

Hmm, seems like there's some room for interpretation. Yet another
question for the FO WG. Sigh.

I guess we're not so bad off with the current handling, so I'll let it
be for the moment and go on to more important tasks. At any rate, this
thread is flagged in my mail client...

Thanks,
Jeremias Maerki



Re: block-containers with BPD set

2005-01-27 Thread Jeremias Maerki
Thank you, Victor, now I think I finally understand what you mean.
However, I see is that this could lead to very funny results. Imagine a
BC with BPD set, overflow=repeat and reference-orientation=180. When the
contents overflow the first VPA, a new one is created under the first
(in BC parent's BP direction), if there's enough room for a second VPA
on the same reference area. If you looked at the paper upside down after
printing, it would look like this (the number indicate the order of the
blocks inside the BC):

5
6
7
8
1
2
3
4

Just for the fun of it. :-) I know it's a bit exotic.

I don't quite see the use-cases for this whole thing yet. But for XSL
1.0 it essentially means that there's only one VPA if the BPD is set,
right? So the current implementation in FOP would be ok for now.


Jeremias Maerki



block-containers with BPD set

2005-01-26 Thread Jeremias Maerki
Thanks for all the comments so far on my questions. I'm afraid I have to
postpone some of the issues, however.

Now, I've got a different problem. I run accross a bug in layout
concerning block-containers with height/BPD specified
(absolute-position=auto). I tried to fix it but I can't find the
passage in the spec that tells me how to deal with the space that is not
allocated by descendant FOs inside the block-container.

Is this space considered as part of the padding-after, and if yes with
what conditionality?

The problem is page/column breaking. Normal blocks can be broken between
lines which is probably also the case for plain block-containers (no
properties specified). But as soon as the BPD is predefined
(autoheight=false) it is unclear to me how to handle it.

I also saw that in the 1.1 WD there is an issue (see block-container)
that may be related to this, but it didn't help.

Any pointers are appreciated.

Jeremias Maerki



Re: block-containers with BPD set

2005-01-26 Thread Jeremias Maerki

On 26.01.2005 18:43:58 Victor Mote wrote:
 Jeremias Maerki wrote:
 
  Now, I've got a different problem. I run accross a bug in 
  layout concerning block-containers with height/BPD specified 
  (absolute-position=auto). I tried to fix it but I can't 
  find the passage in the spec that tells me how to deal with 
  the space that is not allocated by descendant FOs inside the 
  block-container.
  
  Is this space considered as part of the padding-after, and if 
  yes with what conditionality?
 
 BPD and IPD both specify the size of the content-rectangle, so no part of
 unused BPD could be considered part of padding.

Makes sense.

  The problem is page/column breaking. Normal blocks can be 
  broken between lines which is probably also the case for 
  plain block-containers (no properties specified). But as soon 
  as the BPD is predefined
  (autoheight=false) it is unclear to me how to handle it.
  
  I also saw that in the 1.1 WD there is an issue (see 
  block-container) that may be related to this, but it didn't help.
 
 I'm not sure I understand the question or know the answer. What I think you
 have described is an area with an absolute size and a relative position that
 does not fit in the current column or page, but that may not use all of the
 available BPD. Regardless of how well the contents fit inside the area,
 doesn't such an area have to be forced to the next page or column (unless it
 floats and can be moved so that it does fit)? The 1.1 spec (6.5.3) clarifies
 this a bit by saying All generated viewport-areas are subject to the
 constraints given by the block-progression-dimension and
 inline-progression-dimension traits of the fo:block-container. I take this
 to mean that a block-container might generate more than one such
 viewport-area if the contents are too big to fit into one (subject to the
 1.1 issue that you mention), but that, in any case, if the contents are too
 small, the generated viewport-area must meet the IPD and BPD constraints.
 The user can specify IPD and BPD as length-range if they want to allow the
 rectangle some flexibility in how it is sized.
 
 HTH.

It does, at least a bit. Anyway, maybe I should ask the question in a
different way:

Given a block-container where the BPD is specified, are its children
subject to column/page breaking if the whole block-container doesn't fit
into the available area in BP direction? If yes, how is the remaining
space in BP direction which is not taken up the BC's children to be
handled?

The quote you provided above probably point in the right direction. But
I guess my problem is that I haven't found the part of the spec, yet,
that establishes this constraint for block-progression-dimension. I've
searched the spec back and forth and haven't found anything. After a lot
of thinking I believe it's chapter 4.3.2 Overconstrained space-specifiers,
but I don't understand how this explains whether to do breaking inside
the block-container or not.

Thanks,
Jeremias Maerki



Re: Layout dimension mechanism

2005-01-24 Thread Jeremias Maerki

On 22.01.2005 18:42:20 Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
  
  I'm beginning to think that the layout dimensions
  should be held and provided
  by the layout managers instead of the FObjs. 
 
 (learning here...)
 
 Can you point me towards FObjs which are currently
 holding the layout dimensions -- I want to try to
 understand more of what you're talking about.

There are many. The layout dimension map is in FObj. Any FObj can hold
certain layout dimensions.

 I assume you mean the ipd and bpd values only, or are
 there other values which constitute layout
 dimensions?  I'm not certain of the range of values
 that layout dimensions consist of.

There are other values, too. Have a look at
org.apache.fop.datatypes.LengthBase and ...PercentBase which has a list
of different values and value calculation rules.

 
  To
  evaluate a
  percentage-enabled value the layout manager would
  have to call
  getLength() with some kind of context object that
  allows it to fetch the
  right base values for percentage calculations. 
 
 I assume you're referring to property contexts as in
 [1] below, correct?
 
 [1]
 http://www.w3.org/TR/2001/REC-xsl-20011015/slice5.html#section-N6968-Property-Context

Not exactly. There's some relation but essentially I'm talking about a
simple Java interface or object which provides context information for
the value calculations.


Jeremias Maerki



Re: cvs commit: xml-fop/test/layoutengine/testcases external-graphic1.xml external-graphic2.xml

2005-01-24 Thread Jeremias Maerki
Oops, sorry! And thanks for catching it.

On 24.01.2005 23:03:56 pietsch wrote:
 pietsch 2005/01/24 14:03:56
 
   Modified:.build.xml
test/layoutengine/testcases external-graphic1.xml
 external-graphic2.xml
   Log:
   Replaced absolute image paths with relative


Jeremias Maerki



Layout dimension mechanism

2005-01-21 Thread Jeremias Maerki
Team,

I think there is something fundamentally wrong with the layout dimension
mechanism. I've found two problems, one minor, one very bad:

1. While implementing percentages for background-position-horizontal and
-vertical, I realized that it wasn't so simple to base the calculation
on a simple value. The percentage base is actually the padding-rect-size
minus the intrinsic size of the background image. Of course, this value
could be set by each layout manager but it seems awkward to have to do
that everywhere. Instead, I can easily calculate this in
TraitSetter.addBackground(), provided the BPD and IPD of each Area is
properly set before calling TraitSetter.addBackground(). That's
currently not the case, however. But it's probably a good idea to do
that anyway.

2. The above let me calculate the background image position easily for
block-containers. When I wanted to check the same for the body region I
found some bugs that I'm not yet testing for. While trying to fix them I
found a problem when I specify width=height=100% on a block-container
as the only child of a flow. The BLOCK_IPD and BLOCK_BPD layout
dimensions were fetched from the Root which returned the page size
instead of the content-rect size of the current region body area (which
is wrong for documents with different page sizes throughout the document).
PageSequenceLayoutManager also sets the page size as BLOCK_IPD/BPD on
each Region (which is wrong, too). In principle, the BLOCK_IPD/BPD
should come from the currently applicable Region if there's no parent
block-level object.

I'm beginning to think that the layout dimensions should be held and provided
by the layout managers instead of the FObjs. To evaluate a
percentage-enabled value the layout manager would have to call
getLength() with some kind of context object that allows it to fetch the
right base values for percentage calculations. I haven't fully made up
my mind about that and I'd like to hear what you guys think about this
problem.

Jeremias Maerki



Background images

2005-01-20 Thread Jeremias Maerki
Team,

I'm going to implement background images as one of my next steps. I
found that even in 1.1 WD there's no way to scale the background image.
Should we skip that or should we define our own properties? Maybe Glen
wants to talk to the WG about that.

Jeremias Maerki



Re: Background images

2005-01-20 Thread Jeremias Maerki

On 20.01.2005 19:37:06 Glen Mazza wrote:
 --- Jeremias Maerki [EMAIL PROTECTED] wrote:
 
  Team,
  
  I'm going to implement background images as one of
  my next steps. 
 
 Good.
 
  I
  found that even in 1.1 WD there's no way to scale
  the background image.
 
 Jeremias, please do another scan first of the 1.1
 document--thankfully it's all in one HTML file--search
 for both scale and scaling throughout to (1) make
 sure that is the case (there appear to be some new
 properties and even formatting objects related to
 scaling), and (2) to see if there is any scaling logic
 that you're contemplating that may be applicable in
 other areas as well.

Thanks for the tip. The scan turned up empty. All scaling enhancements
seem to apply to external-graphic only.

 Next, you may wish to check the AntennaHouse and
 RenderX extension element/attribute list.  There may
 be something you can learn there about background
 scaling, also when you send emails to the xsl-editors
 list saying [insert commercial company here] already
 does this, etc., it will carry more weight.

I've seen the RenderX extensions. It's really surprising that RenderX
didn't manage to bring that in, yet.

  Should we skip that or should we define our own
  properties? 
 
 I don't care either way.  Although I don't understand
 why the specification doesn't already handle
 background image scaling.  Something is rotten in the
 State of Denmark here--this would seem to be a common
 need.
 
 
  Maybe Glen
  wants to talk to the WG about that.
  
 
 Would be delighted.  But imaging issues are beyond my
 scope, and it's about time the WG learn more about you
 as well.  Please do so, also mention that you're from
 FOP as well please.  (Not that you need my
 permission.)
 
 (This is gonna be great--with both of us sending
 comments to the W3C, we can use a good-cop/bad-cop
 technique to persuade them.  Guess which role I want
 to play? ;)

LOL! I'll try to write something, but I guess I have some other
priorities first. I'll probably also skip these scaling things for now.
This can be added later. My enhancement to parse the bitmap resolution
might also help a bit in the meantime.

Jeremias Maerki



Re: cvs commit: xml-fop/src/java/org/apache/fop/render/xml XMLRenderer.java

2005-01-19 Thread Jeremias Maerki
You're right. The check is not really needed. I simply assimilated that
part to the one in startPageSequence. So, there's no real reasoning here.
I'm aware of the validation scheme for the FO namespace but we're
talking about renderers which don't necessarily follow the same
structure as the FO tree. The problem was rather that:

The page-master1.xml test case I checked in contains several
page-sequences. Now, the XML renderer gets all page-sequences first
(because these calls are made during layout stage) and in the last
page-sequence all pages of the document appear (even if they are in
different page-sequences). That's what it looks like right now:

?xml version=1.0 encoding=UTF-8?
!--Produced by FOP Version 1.0dev--
areaTree
  pageSequence/
  pageSequence/
  pageSequence/
  pageSequence/
  pageSequence
pageViewport bounds=0 0 36 36
  page
snip/
  /page
/pageViewport
pageViewport bounds=0 0 36 36
  page
etc. etc.

That is primarily bad for testing but not necessarily bad for normal
renderers so I didn't take any action for now. But we may want to check
if we want create an area-tree level wrapper for pages in a
page-sequence.

On 20.01.2005 05:46:36 Glen Mazza wrote:
 I don't think this is needed (unless I'm missing your reasoning here.)  
 The validation in the FO Tree would raise errors otherwise, at least one 
 page-sequence being required by the fo:root FO.  The validation scheme 
 was designed so you don't need subsequent safety checks further downstream.
 
 Glen
 
 [EMAIL PROTECTED] schrieb:
 
 jeremias2005/01/19 13:45:07
 
   Modified:src/java/org/apache/fop/render/xml XMLRenderer.java
   Log:
   Safety check
   
   Revision  ChangesPath
   1.38  +3 -1  
  xml-fop/src/java/org/apache/fop/render/xml/XMLRenderer.java
   
   Index: XMLRenderer.java
   ===
   RCS file: 
  /home/cvs/xml-fop/src/java/org/apache/fop/render/xml/XMLRenderer.java,v
   retrieving revision 1.37
   retrieving revision 1.38
   diff -u -r1.37 -r1.38
   --- XMLRenderer.java   18 Jan 2005 08:55:58 -  1.37
   +++ XMLRenderer.java   19 Jan 2005 21:45:07 -  1.38
   @@ -313,7 +313,9 @@
 * @see org.apache.fop.render.Renderer#stopRenderer()
 */
public void stopRenderer() throws IOException {
   -endElement(pageSequence);
   +if (startedSequence) {
   +endElement(pageSequence);
   +}
endElement(areaTree);
try {
handler.endDocument();



Jeremias Maerki



Re: another nose for the grindstone

2005-01-17 Thread Jeremias Maerki
Hi Mark

We'd love to have you with us.

On 17.01.2005 05:18:23 Mark Brucks wrote:
 I'd like to join the fop development group.  I've been an xsl/fop user 
 for the last year or so (generating PDF), but several new projects I'm 
 proposing have a need for a robust and complete awt renderer, and I'd 
 like to devote some time to ensuring this happens.  I have a little bit 
 of time in the near term to commit to the project, and I hope much more 
 time starting in the April time frame.  I'd like to use the next 2 
 months to come up to speed, then dive in to serious work when more time 
 is available.

The AWT renderer is currently missing in CVS HEAD. It would be great if
someone took up that task. To build that renderer you can look at the
code from the maintenance branch (or FOP 0.20.5) for reference. Our
reference renderer in CVS HEAD is the PDF renderer (like before).

Personally, I'd rather call it Java2D renderer, not AWT renderer,
because Java2D is essentially the name of the API you code against. AWT
is, as the name says, a windowing toolkit, not primarily a graphics API.

 I need some advice.  I've learned enough about xsl and fop to get my job 
 done, but there are lots of holes in my knowledge base.  I'd like to 
 spend a little bit of time carefully reading the XSL spec.  Should I 
 read the XSL V1.1 working draft (in anticipation of things to come), or 
 should I stick with the V1.0 recommendation (which I assume is what the 
 new version of fop will implement).

The recommendation is still the main reference. Glen Mazza already
started investigating the 1.1 WD (ex. bookmarks) and it might be helpful
sometimes to consult the 1.1 WD because it seems to be somewhat more
verbose. It's good to prepare for 1.1 but as long as it's in WD phase
the focus should remain on the 1.0 Rec for the time being.

 Do the development and design documents that are available on-line 
 relate to the root/trunk/redesign version, or do they still describe the 
 maintenance branch?

They refer to CVS HEAD. If they are not up-to-date, they should be
updated.

 Is there a development schedule or a prioritized list of features to be 
 implemented?

A development schedule is always difficult in an all-volunteer project.
I think it's pretty realistic now to target an initial release in late
summer 2005.

I'm currently working off this list: 
http://wiki.apache.org/xmlgraphics-fop/FOPWorkEstimates

But this list isn't binding. You're free to choose what you like to work
on. If you want to build the Java2D renderer, that's great. If you want
to help with the layout engine, even better. If you start a task simply
notify us what you're working on so we don't have duplicate effort.

 Is anybody else actively working on the awt rendered for the next release?

No, not at the moment.

 Since this is my first foray into open-source development, any and all 
 advice is welcome.

The advice is simple: Choose something to work on, notify this list (if
it's something bigger), start hacking and in the end send patches via
Bugzilla. Of course, this is a bit simplistic but essentially this is
all what you need to know for now. :-)

If you have questions simply ask. We're happy to help you getting
started.


Jeremias Maerki



  1   2   3   4   5   6   7   8   9   10   >