AW: What should I be doing ?
It might be helpful to take the renderer programmer's view: - A meaningful renderer interface has to be specified now, i.e. the representation of pages either in memory or serialized. More supported XSL properties lead to bigger storage requirements. - Renderers take over pages consisting from some graphic objects with absolute sizes and positions. Anything between FO input and these graphics is completely irrelevant to renderers. - Layouters and area tree builders may produce fantastic documents on an extremely efficient way, conforming to specifications etc.: but what, if renderers are not able to render graphic objects, to handle orientations and directions - as it's the case with the PCL renderer nowadays? - Testing, validation is another topic. Java2D is the reliable rendering system unless you want to use the Adobe product as benchmark. When it comes to a Java2D renderer (former AWT renderer), there are these facts regarding text rendering, font support: o Java supports TrueType, OPI and Type1 fonts o XSL properties : Java TextAttribute's = 1:1 - TextAttribute maps give a binary object representation for XSL font properties in Java (more Float's than int's) - Java2D 1.4 does not process stretch and weight properly (hopefully fixed in Java 1.5), variant is not supported - font face picking by Java 1.4 is funny: a static font mapping is required to get predictable results o Java2D supports font metrics, i18n, bidi and Unicode well o Java2D does not support - word and character spacing: may be programmed by inserting white space - kerning: info not available in font metrics Similar observations apply to Java2D strokes, rectangles and images. Hansuli Anderegg
DO NOT REPLY [Bug 25582] New: - [PATCH] Remove unused imports.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582 [PATCH] Remove unused imports. Summary: [PATCH] Remove unused imports. Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Minor Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The default setting for eclipse marks unused import statements as a warning. This patch removes the unused imports and makes FOP a tiny bit more eclipse friendly.
DO NOT REPLY [Bug 25582] - [PATCH] Remove unused imports.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25582 [PATCH] Remove unused imports. --- Additional Comments From [EMAIL PROTECTED] 2003-12-17 08:21 --- Created an attachment (id=9611) A unified diff against HEAD
RE: FOs and Areas
J.Pietschmann wrote: Victor Mote wrote: I guess you are saying that a page-sequence will use too much memory (??). Again, this is a non-issue. Just use a different LayoutStrategy that is more eager. This can be an issue. In a real world file I benchmarked (rendered to 58 pages), the FO tree for the second page sequence run up to 70MB due to a table with lots of small cells, which generated more than 80k FOs alone. This also generates a huge amount of areas, even if they are discarded almost as fast as possible, it is easy to max out a 512MB VM configuration. And that's by no means an completely unreasonable example. I wondered why I got a OutOfMemory already during *parsing*... You must have missed the previous parts of the thread. Your response has nothing to do with the issue being discussed. Yes, we can no doubt make the parsing more efficient, the storage of the FO Tree less costly. But that was not the issue on the table. Victor Mote
RE: FOs and Areas
Peter B. West wrote: The statements are getting extreme. Let's just agree to differ. I'm happy to let my code and the design that underlies it do my talking. OK. For the reasons already mentioned, this does not work for me. I consider this kind of behavior to be uncivilized. However, I have to consider the possibility that the problem lies with me. Since this is the second time in the last several months that I have had to call someone out for unsupported (and unsupportable) conclusions, and since I have had to do so alone, and indeed stand alone here, it seems probable that this is just the way things work, and that I should somehow adapt myself to it. That ain't going to happen. I would rather go away than to be the guy that everyone wishes would go away. So, adios. I have a great amount of respect for everyone on this team, and wish you all well. I very much regret leaving my various interests in the project unfinished. Victor Mote
RE: FOs and Areas
-Original Message- From: Victor Mote [mailto:[EMAIL PROTECTED] Peter B. West wrote: The statements are getting extreme. Let's just agree to differ. I'm happy to let my code and the design that underlies it do my talking. OK. For the reasons already mentioned, this does not work for me. I consider this kind of behavior to be uncivilized. However, I have to consider the possibility that the problem lies with me. Since this is the second time in the last several months that I have had to call someone out for unsupported (and unsupportable) conclusions, and since I have had to do so alone, and indeed stand alone here, it seems probable that this is just the way things work, and that I should somehow adapt myself to it. That ain't going to happen. I would rather go away than to be the guy that everyone wishes would go away. So, adios. Victor, With all due respect, I think you're overreacting here. Maybe you already know this yourself, and have changed your mind about the 'adios'... Anyway, I have been following the discussions between Peter and yourself (--at least the recent ones, which may be exactly why I'm convinced this is all strongly exaggerated). Before you leave, I have a thing or two to add about one of the previous posts in this thread, where you are talking about an abstract 'team' where at first 100 percent of the committers are pro one particular design --you know, the part about 'choosing sides' and how this affects global efficiency within a project. Since the post in question was composed shortly after my 'heads up' to Peter, I can't help but feel it's somehow related to that. Perhaps you would rather have seen me (or others) having a go at him as well? It definitely was never my intention to occupy myself with something so mean/common as 'choosing sides'. Fact of the matter is that, for the moment I *know* too little about the workings of FOP (either HEAD or alt-design) to actually have a thoroughly reflected preference for either approach. Hey, maybe I just need to catch up on the archives, and will then suddenly discover what kind of a pest Peter really is... but right now, I lack any indication of him trying to undermine every one of your design proposals, neither have I been confronted with any evidence that he is actually trying to force anyone to see things *his* way at the cost of everything else (and these are two things you seem to be _reproaching_ him in your replies). Re-reading Peter's posts, on the contrary, I see someone who was daring enough at some point to say: I'm going to try it like that, regardless of what the rest of you does. Some time later, he came to the conclusion that he wouldn't solve some of the issues the others were trying to solve at the time he went his own path, and now he's here again --to see if any of the issues have already been sorted out. Look, I can understand your agitation stemming from the fact that you had put considerable time and effort into providing a means to be able to choose between different layout strategies, and now it turns out this wasn't really necessary after all --and Peter's shrugging his shoulders, which obviously would cause a lot of frustration with (and would thus come across as offending to) someone who takes the project seriously, like yourself. However, right now, reacting the way you do, I'm getting the impression you're taking it waaay *too* seriously --in fact, you have been doing that all along. It almost seems like you are backing out now, because you see a certain failure ahead and you want to avoid it. You just don't want to be there when it turns out your proposals were worthless to begin with. Nowhere have I read any allusion to you as the guy everyone else wishes would go away (perhaps somewhere in the whitespace in between two words in one of Glen's posts ;) ) Things get rough sometimes, not everyone is as fluent in expressing himself in writing, and, as it turns out, not everyone seems to be as fluent in reading what is written... I have a great amount of respect for everyone on this team, and wish you all well. I very much regret leaving my various interests in the project unfinished. To be honest: whether you decide to stay or not, I'll certainly be frequenting this list for some time to come... too bad I just considered myself ready to start studying your FO tree in more detail ( Peter could turn out to need it as well ) :) Cheers, Andreas
Re: FOs and Areas
Peter B. West wrote: (does Jrg work?), Not in the archive. I know you are a long-time advocate of sticking with the codebase, and have been very critical of my approach, so I don't want to draw any unwarranted conclusions here. Does the above mean that you are interested in my ideas? I've got a lot of ideas myself, perhaps too many. What the project needs is *working* *code*. J.Pietschmann
Re: FOs and Areas
On Wed, 2003-12-17 at 15:56, J.Pietschmann wrote: I've got a lot of ideas myself, perhaps too many. What the project needs is *working* *code*. Amen! [but a short one, not drawn out like the final chorus of Messiah!] -- John Austin [EMAIL PROTECTED]
Going away (was: FOs and Areas)
On 17.12.2003 15:25:37 Victor Mote wrote: I would rather go away than to be the guy that everyone wishes would go away. Ok, Victor, until that happens I'd like you to stay. I don't see *any* indication that *anyone* wishes that *anybody* should go away. Well, our moderators would surely like to get rid of all spammers. But seriously, please reconsider your decision, maybe take a break from the mailing list to clear your head. Consensus is sometimes hard to find especially over such an problematic medium such as this mailing list. Intentions are always difficult to transmit. Mails take a long time to write, time we usually don't have and would rather spend programming. I think we all share that frustration. Maybe we should all buy a webcam so we can occasionally chat together face to face as we're all a long way from each other. Now the following is not only directed to you, Victor, but to everyone else as well. Just personal opinions: I followed the wars on the Avalon mailing list which at one time even produced a victim in form of a partial expulsion from the ASF. I would be very sad to have to see similar things here, especially in the project's present state. I told Glen this summer that it's better to fire away with changes than letting himself block by myself who, at that time, only injected his ideas and opinions but without code to back them. What this project needs is people who simply do it (tm). A good design is useful but obviously it's not so simple to find in our case. We can't live without some sort of design that gives use some direction but things like Victor's pluggable LayoutStrategy may really help, if we need to investigate different approaches. I'd rather have two or three half-completed layout approaches with lots of things learned than not a single working one with a community at total stand-still. We failed to integrate Peter's branch into HEAD but maybe that's also because it was too big a bundle at one time. Everyone should accept that another person has a different opinion. That shouldn't block us in our work. We all look forward to the same goal. That much I know or else we wouldn't be here. So, I mostly agree with Joerg's and Andreas' recent comments. Please let's focus on coding even if we may have to throw away little parts again in the process. (This doesn't mean I don't want to see anymore threads on design.) I think one of the most important points we learned since the redesign decision is to better split up the whole thing so it's easier (and less painful) to change if we run into a dead-end somewhere. Jeremias Maerki
RE: FOs and Areas
-Original Message-
From: John Austin [mailto:[EMAIL PROTECTED]
On Wed, 2003-12-17 at 15:56, J.Pietschmann wrote:
I've got a lot of ideas myself, perhaps too many. What the
project needs is *working* *code*.
Amen!
[but a short one, not drawn out like the final chorus of Messiah!]
Well, just helps if you have ideas to share these from time to time, whether
it's working code or not. It has proven to provide very interesting clues
when it comes to getting pointers on where to look for which particular
mechanism, and on how these could be improved, possibly at very low-level.
So to add some :
-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED]
I wondered why I got a OutOfMemory already during *parsing*...
Which is done by {which parser?} ... Just asking because on Xerces-J's
feature page
( http://xml.apache.org/xerces2-j/features.html ), I saw a little note on
'http://xml.org/sax/features/string-interning' (--with all the rant on
String.intern() a while ago, this _may_ provide a clue to some; or may well
be a well-known fact, perhaps already explored ).
Anyway, it defaults to 'true' for any parser that is derived from the Xerces
default parser (you can't even unset it)
Perhaps (--a long shot) the earlier attempts to try and use this blocked on
the internalizing being doubled in some way?
... In a real world file I benchmarked (rendered to 58 pages),
the FO tree for the second page sequence run up to 70MB due to a table
with
lots of small cells, which generated more than 80k FOs alone.
80k? For how many fo:* approx. in the file? Guess that's the counterweight
for verbosity mandated by the spec... a fo:block could consist of only one
node, an fo:table still takes at least five (six in the exotic case you
actually need to place some content in the cell, for testing purposes ;) )
Problem seems to be one of nested little objects, no longer 'needed', but
still referenced by their parent, which is still 'needed' --btw: What
exactly are the criteria by means of which it is possible to decide that a
given FO object, no matter how deeply nested, can safely be 'discarded' from
the tree? I mean not solely from the spec point-of-view: it would of course
be possible for an object to refer to another defined at the start of the
page-sequence, but does that necessarily mean having to keep a reference to
all of the latter object's descendants?
[Another option (--also a very long shot maybe) would be to try and, ahem,
_steal_ a little of the PDF approach... implement a form of (binary)
compression on the FO tree storage in memory? Since zipping objects already
has the known benefit of saving bandwidth, why not try and use it to reduce
footprint? Compress in static form, decompress the objects (and their
descendants) as-and-when they get needed by Layout/Area tree. In cases as
mentioned above this would already decrease memory fp by, what? 30%? Taking
into account you still have to have uncompressed instances of objects needed
by the other running processes (apart from tree building). Would it weigh up
to the processing cost?]
Just an idea...
Cheers,
Andreas
RE: cvs commit: xml-fop/src/java/org/apache/fop/fo Constants.java
It's been in that location for at least several months--it's just that we never saw it because it was autogenerated and never checked into CVS. (As for its location--it is used by the FO classes and it also has some FO constants and other enumerations in there, so it is OK remaining there, I think.) I pulled that class off its autogenerated pedestal and checked it into CVS. Also added Finn's properties and fo constants, or slight variations of them. The latter are still unused--there's more work needed to be done to get us on to int constants. I've been working on it continuously--after work and on weekends, since about Saturday. And we may also need to rearrange the property constants if we're to use Alt-Design's resolution method, I don't want to gratuitously have Peter's implementation ruled out just because of the ordering of some constants. (Now ruling them out if his method proves sluggish, OTOH, is another matter... ;) But I'm not there yet. There's about 10-15 differences between Alt-Design and HEAD (my unresearched guess), and getting us on to INT constants--the no-brainer--removes one of them. Peter hopefully will start to see more of the theory of Alt-Design in HEAD, if not exactly the same implementation (e.g., like Finn, I have a slight preference for a constants interface--Constants.java--that classes can implement, rather than a constants class--PropNames.java.) Glen --- Andreas L. Delmelle [EMAIL PROTECTED] wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] 1.1 xml-fop/src/java/org/apache/fop/fo/Constants.java Index: Constants.java === /* $Id: Constants.java,v 1.1 2003/12/15 01:07:50 gmazza Exp $ * == == Glen, Shouldn't this one go into fop/fo/properties? This one puzzles me as well... In the props design in head, I found a lot of little interfaces declaring static finals with values from the fop.fo.Constants class. Anyone? Cheers, Andreas __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
