RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
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
Re: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
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
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
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
(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 wi
RE: DO NOT REPLY [Bug 33760] New: - [Patch] current AWTRenderer
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
Re: remove build.bat and build.sh?
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: [XML Graphics - FOP Wiki] Updated: PageLayout
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
