Re: Getting breaks: revisited
On Tue, 2002-12-03 at 21:56, J.Pietschmann wrote: Oleg Tkachenko wrote: btw, how does such a case addressed by the spec? Apparently FOP, antenna and xep do squeeze content. Isn't it an example of overconstrained geometry (5.3.4)? It can be interpreted as such in the presented case. Use height instead of width and a table whose rows are kept together instead of a block to make it more interesting (from the users point of view, for the processor it may still be an example of overconstrained geometry, but this becomes far fetched rapidly). That suggests to me that the spec needs some work. How can it possible mean that it should go through every single possible combination of pages/blank pages to come up with a suitable solution. Does the area tree allow for multiple breaks between areas in the flow? (not including forced breaks) It doesn't say either way (that I can find) but I would hope the answer is no. Then you could say that anything that starts on the page will ensure that some of it is placed on the page. The keeps are dealt within the context of that page (and further flow) until a forced break but not in terms of an arbitrary future page that might fit the current content. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15048] - Unwanted page break after image linked by external-graphic in region body
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=15048. 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=15048 Unwanted page break after image linked by external-graphic in region body [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 10:21 --- page-break-before=avoid is a shorthand of keep-with-previous=always (the same for page-break-after=avoid), but it's documented limitation of the current version that keep properties are only supported on table rows. It's addressed by the redesign process under way. Usual workaround is a blind table with keep-* properties on its rows. *** This bug has been marked as a duplicate of 3044 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3044] - keep-together not functioning
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=3044. 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=3044 keep-together not functioning [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 10:21 --- *** Bug 15048 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: alt.design info
sri vela wrote: I would like to know about fop alt.design. Where can i find the documentation for this? will it change the entire old design ro part of it? What should i do to involve in alt.design. It's http://xml.apache.org/fop/design/alt.design/index.html -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
CVS of the maint. branch
Hello together, i'm looking for the current cvs version of the maintenance branch (0.20.5). I have no possiblity to get it through CVS (our firewall blocks that). Is there another way to get the source of the current version? -- regards Timo Haberkern EMEDIA OFFICE GmbH Wingertstr. 4 74850 Schefflenz-Kl. http://www.emedia-office.com thaberkern at emedia-office.de Tel.: 06293/921121 Fax: 06293/921129 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: CVS of the maint. branch
Timo Haberkern wrote: i'm looking for the current cvs version of the maintenance branch (0.20.5). I have no possiblity to get it through CVS (our firewall blocks that). Is there another way to get the source of the current version? afaik, no way. Nightly snapshots hold the trunk code. Ask your admin to open port 2401 or try some kind of proxy. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
bug #13586
Hello there! What do you think about http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13586? Stefan asks us to use something like float currentLetterSpacing = (float) 9.99; instead of float currentLetterSpacing = Float.NaN in PDFRenderer.java due to jre-1.3.1 for linux-alpha bug. For me it looks too patchy. I suggest to resolve the bug as WONTFIX as anybody suffering from it able to make the modification in the code. It's only 1 line after all. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 14248] - 51-page FO example, could be added to the samples
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=14248. 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=14248 51-page FO example, could be added to the samples [EMAIL PROTECTED] changed: What|Removed |Added Severity|Minor |Enhancement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Why use XML configuration files?
Hello, I noticed that the apache project uses mostly XML files for configuration. Personally I prefer using .properties files because then I don't have the overhead of parsing the file each time. So what's the advantage of using XML files? Thanks for any answers... Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 8635] - FOP replace japanese chars into # on Linux
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=8635. 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=8635 FOP replace japanese chars into # on Linux [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:39 --- Excuse me, but it's not enough information to resolve the bug without your assistance. Feel free to reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12268] - FOP 0.20.4 cause PDF buffer append for each rendering.
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=12268. 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=12268 FOP 0.20.4 cause PDF buffer append for each rendering. [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:40 --- Excuse me, but it's not enough information to resolve the bug without your assistance. Feel free to reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12864] - Incorrect behaviour for multiple columns on page
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=12864. 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=12864 Incorrect behaviour for multiple columns on page [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:41 --- Excuse me, but it's not enough information to resolve the bug without your assistance. Feel free to reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13295] - different results using xml or fo (from the same xml-file)
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=13295. 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=13295 different results using xml or fo (from the same xml-file) [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:42 --- Excuse me, but it's not enough information to resolve the bug without your assistance. Feel free to reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13451] - rendering of SVG with strokeSVGText = false causes exception
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=13451. 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=13451 rendering of SVG with strokeSVGText = false causes exception [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-04 17:43 --- Excuse me, but it's not enough information to resolve the bug without your assistance. Feel free to reopen the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FOP schema
While working on an FAQ for FO dtd schema, I see that we have two schema in docs/foschema: fop4f.xsd fop4.xsd. They are similar. Does anyone know what the purpose for both is, why we have 2, or the 4 4f designations? Thanks. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
bugzilla shake-up is over
Hello there! Well, bugzilla shake-up is over, sorry if I closed something not-to-be-closed or leave something-to-be-closed, but anyway I believe we can say bugzilla is cleaned up now. Now it's 111 entries in there (it was 188 IIRC): Blockers: 3 Criticals: 6 Majors: 17 Normals: 67 Minors:6 Enhancements: 12 There are 4 patches among them. Not bad. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP schema
Victor Mote wrote: While working on an FAQ for FO dtd schema, I see that we have two schema in docs/foschema: fop4f.xsd fop4.xsd. They are similar. Does anyone know what the purpose for both is, why we have 2, or the 4 4f designations? I think fop4f.xsd is the latest one. Anyway Chuck Paussa [EMAIL PROTECTED] knows better. -- Oleg Tkachenko eXperanto team Multiconn Technologies, Israel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: FOP schema
Victor Mote wrote: While working on an FAQ for FO dtd schema, I see that we have two schema in docs/foschema: fop4f.xsd fop4.xsd. They are similar. Does anyone know what the purpose for both is, why we have 2, or the 4 4f designations? Victor, I think that Chuck was appending a letter to each version of the schema. When he submitted fop4g.xsd, I cleaned the tabs out of fop4f.xsd, and committed that file as fop4.xsd. I then did similar clanups on fop4g.xsd, and committed that as a change to fop4.xsd. So from fop4.xsd, you can recover the latest two versions of the file. fop4f.xsd is for historical reference only, left in case there were any problems with my cleanups of fop4.xsd. At the time I let Chuck know what I had done, and asked him if he could submit a diff against that file as his next version. See http://marc.theaimsgroup.com/?l=fop-devm=103547432006815w=4 Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Redesign issues
Arved Sandstrom wrote: You're being absolutely honest, which is cool - I'll be absolutely honest also. It seems to me like the mainstream rewrite is in trouble. Very few people understand it or have [clearly] bought into it. This is no comment on its technical merits, by any means. OTOH, only one person has been working on the alternative - you yourself, Peter. So what we really have is 3 projects: maintenance, rewrite, and alternative, and most of the committers and developers seem to be working on maintenance. Correct me if I'm wrong. In a sense, we have four. Although xslfo-proc is being developed in another place and language, you are still very much a part of this development community, active of not. I nominate xslfo-proc as the fourth project because, to the best of my knowledge, you and Eric are taking a different approach to design again. And the design, as you point out, is the critical issue. Whatever success you have with design in xslfo-proc should be of great interest here. The problems you describe in your email are symptoms, in my opinion. Forrest is irrelevant...we have bigger problems. In fact, pull vs push vs tree is also irrelevant, because that is dancing around the big issues - understanding the FO spec, and being able to implement it. Has anyone so far, for example, described a clear vision for properly handling keeps? A comprehensive vision, no. But what I consider to be some necessary elements of the solution, yes. And I firmly believe that the problem is comprehensively solvable. No, they haven't. Does anyone here think the FO problem is non-deterministic? Raise your hands, please. :-) No? In which case, why (years after this project started) do we not have clear algorithms stating exactly what we will do in various situations? This is the question that everyone has to answer. Blind faith that that the problem can be solved by simply hurling onself at it is not enough. I'm not saying that Keiron and Karen are in that situation, but I suspect that others are. An elegant and comprehensive plan of attack, including a design approach that can confidently be expected to crack the toughest problems, may exist in their imaginations, but it needs to be made manifest before any sort of team attack can be made on the problems. My impression though (and I am happy to have my ignorance corrected on this) is that the redesign is being attempted piecemeal, without a broad overview. If I am correct in this, it would be largely explained by the complexity of the problem, and the determination to retain as much as possible of the existing code base, and therefore, of the existing design. If I am wrong in this, it may be symptomatic of, in addition to my laziness and obtuseness, inadequate top-level documentation (including diagramming) of the way the layout is attacked. Whether or not those considerations actually apply in this case, if you are using piecemeal design as a way to attack complexity, you must be prepared to throw things away when they prove not to be fruitful, as many things inevitably will. I could care less at this point about SAX and DOM and pull and push - that's XML processing. Our FO processing algorithms, stated in design notes, should express independently of XML processing model how we will handle every FO situation. I agree with you here. By the time the layout is triggered in the current model, the relevant part of the FO tree has been built, so the layout engine is always working on a complete subtree. However, it seems to me that the existing design, and possibly the redesign, do not take full advantage of this. The alt.design has the advantage of being based on an explicit, fully navigable tree structure. However, that structure is not, in itself, sufficient to express the relationships needed for layout. We have had discussions in the past about tree vs. flat structures for the area tree. I believe that both views are needed simultaneously, and that the flat view can be obtained by running threads of links through the tree to represent page-contiguous elements for the resolution of keeps and space-specifiers, for example. I am not dismissing your concerns, Peter. I just think that we've got bigger ones. We are the committers; we need to decide once and for all what we intend to do. If it assuages your feelings any, I happen to be partial to your pull model - I am personally very comfortable with SAX, but I recognise that most are not. Peter -- Peter B. West [EMAIL PROTECTED] http://www.powerup.com.au/~pbwest/ Lord, to whom shall we go? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
