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

2005-02-28 Thread Luca Furini

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




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 Victor Mote
Renaud Richardet wrote (in Bugzilla):

 http://issues.apache.org/bugzilla/show_bug.cgi?id=33760
 
Summary: [Patch] current AWTRenderer
Product: Fop
Version: 1.0dev

...

 = Points I would like to discuss (see the corresponding FIXME 
 in the code) =
 
 Fonts: I must be missing something with the font-mechanism: 
 the rendered text in the AWTRenderer is smaller that the one 
 of PDFRenderer. What I need is a way to get a java.awt.Font 
 from an area. 
 Is the class FontSetup implemented correctly? Do I have to 
 worry about multibyte-stuff?
 I could investigate the whole mechanism, but a hint would 
 certainly speed my work.

Here are some things that may help:

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.

2. The java awt Font-related classes don't give access to the underlying
font file. This causes problems for the PDF renderer, which needs to be able
to embed fonts in its output. Within FOray, the major distinction within the
fonts is whether they are FreeStanding or System (awt) fonts. Embedding
requires FreeStanding. AWT Renderer requires System fonts. There is some
hope of merging the two at some time in the future, by using
java.awt.Font.createFont method to create the AWT font from the
application's (i.e. FOP/Folio/FOray) font registration system. However Java
1.3  1.4 only support TrueType fonts in this method, and 1.5 only adds
support for Type1, so there are some built-in limitations. (FOrayFont
doesn't support OpenType either, but it is very feasible to add that
ourselves).

3. There are no doubt substantial improvements that can be made to the way
aXSL/FOray handle the System font issue. I would be glad for someone who
actually uses this aspect of the font system (I don't) to comment on it and
suggest improvements.

With the above as some background, I'll try to answer your questions:

 the rendered text in the AWTRenderer is smaller that the one 
 of PDFRenderer.

Some possibilities are 1) because of the dichotomy of the registration and
selection of the fonts, you can actually be using different fonts for layout
and rendering, 2) to the extent that the AWT renderer uses AWT to do the
layout/rendering, there are bound to be differences between that and the way
FOP does it. I wouldn't have expected font sizes to be a big issue, so maybe
there is something else at work here as well.

 What I need is a way to get a java.awt.Font  from an area. 

The aXSL Font interface java.awt.Font getAWTFont(FontConsumer consumer, int
fontSize) method. If the font is a System font, it will return the AWT font
to you. The trick for you then is to be able to get the aXSL font instance
out of the FOP FOTree or AreaTree. I'll defer to the FOP developers to tell
you how to get that done.

 Is the class FontSetup implemented correctly?

It depends upon what you mean by correctly. Like so many other things in
FOP, it kind of works, but is very difficult to improve because of the
underlying design. It is what evolved into the FontServer class in aXSL and
FOray. Much of its data is static, which causes problems when running
multiple documents in multiple threads (fixed in FOray). That may not be an
issue for an AWT renderer, but is an issue when trying to develop a general
solution that will also work for other renderers.

IMO, the whole font subsystem had evolved into an unmanageable mess that
needed a serious cleanup. However, that really is just an opinion.

 Do I have to worry about multibyte-stuff?

For screen display and java printing, I don't think so, since that is all
handled by AWT.

 I could investigate the whole mechanism, but a hint would 
 certainly speed my work.

I am a FOP outsider these days, so maybe one of the committers can add some
more insight.

 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 

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

2005-02-28 Thread Jeremias Maerki
(Comments inline)

On 27.02.2005 23:51:25 bugzilla wrote:
 I've been working on the AWTRenderer those last days. Before I move forward, I
 would welcome some feedback to know if I'm heading in the right direction.

I think you are. Interesting work. Keep it up!

 = What I did =
 
 Basically, I tried to implement in AWTRenderer what the PDFRenderer does. The
 drawback is that all what doesn't work for the PDFRenderer doesn't work for 
 the
 AWTRenderer neither.
 I've posted a patch with the updated renderers. The patch has changes for the
 classes AWTRenderer, AbstractRenderer, PDFRenderer and CTM plus a new class
 BMPReader.
 
 AWTRenderer: I implemented several renderXXX() methods and the corresponding
 helper methods.
 
 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. Each renderer may have a slightly different way
of holding state (currently selected line width, font etc.). So far it
looks good to me even if pulling up currentFontName was necessary.
Ideally, this variable should probably not be in AbstractRenderer I
think.

 PDFRenderer ans PSRenderer:
 I moved 2 lines (currentIPPosition = 0; currentBPPosition = 0; ) in
 startVParea()  because the AWTRenderer uses those values in another way and 
 need
 to keep track of them (see startVParea() in AWTRenderer).
 Speaking of startVParea(), could we rename it to something more meanigfull?
 Proposition: TransformPosition, or something like this.
 Deleted the methods moved to AbstractRenderer. 

Actually, I like startVParea() (or rather startViewportArea like I would
rather call it) because only for viewport a new transformation matrix is
necessary. I think when you port the matrix concatenation from the PDF
renderer over to Java2D in startVParea() you will start to understand
what's going on here. I think the Java2D approach is not unlike the
PDF/PS approach. See Graphics2D.setTransform() and
AffineTransform.concatenate().

 fop.area.CTM: added two getters for e and f. If there's another way to get 
 those
 values, please let me know.

Normally, we use toArray() but I guess these two getters are ok and
don't hurt although I think they are not necessary because you need to
use all other values in the CTM, too, to get the reference orientation
stuff right. See above.

 = Points I would like to discuss (see the corresponding FIXME in the code) =
 
 Fonts: I must be missing something with the font-mechanism: the rendered text 
 in
 the AWTRenderer is smaller that the one of PDFRenderer. 

The AWT/Java2D renderer uses a different font source than the PDF and PS
renderers. The AWT/Java2D renderer gets the font metrics of the
individual fonts from the AWT subsystem. See AWTFontMetrics and
FontMetricsMapper. The different way of getting font metrics may result
in a slighly differently rendered document when compared to PDF. That is
expected and is the same in FOP 0.20.5.

 What I need is a way to get a java.awt.Font from an area. 

I think you are already on the right track with the current
implementation. Simply use PDFRenderer.updateFont() as a reference. The
only thing I see is that you should check currentFontName and -Size to
avoid any unnecessary and costly creation of Font objects. The
FontMetricsMapper should do all the rest for you.

 Is the class FontSetup implemented correctly?

Yes, I think so, although it might be worth checking out if the
available font could be enumerated and registered. On the other side
this might lead to a lot of work being done during setup. Maybe this
stuff could be refactored to do late font resolution (creation of the
necessary objects when needed/requested). Check with a special font (not
Arial or Times or one of the standard fonts) from your system to see
what happens.

 Do I have to worry about multibyte-stuff?

I don't think you have to worry about multi-byte stuff because it will
be handled for you as Java internally uses Unicode and you only send
normal Unicode strings to the Java2D api.

 I could investigate the whole mechanism, but a hint would certainly speed my 
 work.


 Colors: My method updateColor (Graphics2D graphics, Area area) doesn't work 
 for
 some areas.Same question here: how can I get a java.awt.Color from ANY area?

Not sure but I think Graphics2D.setColor() only sets the stroking and
text color. Have a look at Graphics2D.setPaint(). Did you see that you
didn't use the fill parameter of updateColor? if fill is true you can
probably simply set graphics.setPaint(newCol).

Try to consolidate all the updateColor() methods. Also I'd remove
ColorTypeProperty.getAWTColor() to avoid the dependency on
java.awt.Color. Use AWTRenderer.toColor instead and improve this for
non-sRGB colors (if we already have color outsite sRGB).

 There are still many issues with the positioning of the areas. I keep 

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 Victor Mote
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




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: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer

2005-02-28 Thread Victor Mote
Jeremias Maerki wrote:

 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 

I don't mean to be rude or insult anyone, but the help I found at Apache was
a net loss. Sure, there is some real help, but it was far outweighed by the
hindrances. There is something wrong either with me or the way the FOP
community works, maybe both. Of the 18 months that I spent working on FOP, I
consider the last 12 of it to have been utterly wasted. Worse, I probably
wasted other people's time along the way. There is a steady stream of FOP
users who want to contribute to the project who simply cannot find a way to
overcome the obstacles that the FOP committers place in front of them. The
rather thin constituency that allows me to continue working on open-source
publishing software would evaporate if I went down that path again. At the
risk of seeming coy or ungrateful (I hope I am neither) it really is not an
option for me. As for a bigger audience, I am not worried about that. If we
produce something worthwhile, people will find it.

 willing to help. And I don't see a big risk for disputes as 
 there were for the overall approach for FOP.

You may be right, but I have reason to doubt it. If what you say were true,
FOP would have done a 0.21 release in September that incorporated FOrayFont:
a very modest (but real) cost to the project, significant gains to both
users and the project, the fairly speedy removal of a whole class of support
issues, a test-bed for one actual 1.0 module, modest cleanup of the code
base, the opportunity to attract developers to work on a much simpler
discrete subsystem, elimination of the *immediate* need for a competing
product, etc. IMO, that should have been a slam-dunk, but wasn't. Here is a
huge disagreement that has nothing to do with system design at all. As with
many other FOP decisions, I am just baffled.

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

I think we can and should work together, but I see only downside potential
to making the relationship as tight as it once was. My philosophy makes
ample room for making mistakes ... once.

Victor Mote