Re: Maintainability
Manuel Mall wrote: On Thu, 29 Sep 2005 11:50 pm, Peter B. West wrote: Fopsters, I've always been somewhat sceptical of the new approach to page breaking, although I was prepared to concede that it would be a great achievement if you pulled it off. However, the closer the development has come to fruition, the more some of my original concerns have been reinforced. Think about the enormous amount of intellectual effort that has gone into mapping the problem into Knuthian. That effort is still under way. How is this going to be maintained? Where are the Knuthian speakers who are going to do that job over the next few years? I'm surprised, in fact, that some of the old hands have not raised this question already. Peter, I don't get it what you are aiming at here. Are you saying that the Knuth approach to line or page breaking is inherently more difficult to understand and therefore harder to maintain? Apart from being one of the best (in terms of visual quality of the output) algorithms for breaking it is also IMO inherently simple. This is one of the beauties of many of Knuth's works. He is IMO a brilliant Computer Scientist who manages to solve complex problems using simple concepts and algorithms. The concepts and algorithms are also well documented in papers and books which are usually accessible through your nearest university library. Just take the Breaking Paragraphs into Lines paper. Yes, it is over 80 odd pages long but the important concepts are explained in the first 10 pages. In my case, when I delved cold into the fop layout code I had no idea what was going on, but after reading the initial part of the paper it all suddenly made sense. So, where is the problem - Fop is using well documented concepts and algorithms to do its line and page breaking. Why should it be harder to maintain than some home cooked solution not backed up by previous research / papers / implementations (Tex)? And if you take the recent discussions mainly driven by Jeremias regarding the bpd space resolution the core of the problem is not mapping it into the appropriate Knuth sequences. It is the implementation of the space resolution rules themselves, i.e. figuring out how much space to leave or not leave in a particular situation, which is the hard part. Generating the appropriate Knuth sequence once you know what the resolved space is is easy. And quite a few of the stuff is also documented on the WIKI. In summary, and I can speak here from my own recent experience, I don't share your concerns about the Knuth approach increasing the maintainability cost of the fop code base. If you guys are happy with how the design is shaping up in terms of maintainability, great. There had been no discussion about this aspect, now there is. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Sponsorship
Jeremias Maerki wrote: On 29.09.2005 11:58:57 Peter B. West wrote: Jeremias, I meant to ask you when you mentioned your sponsor; who is it? I'm not at liberty to disclose that at this point. I'm sure they're happy with the work you've put in. Yes, they are. We've already achieved one of the major goals: To bring FOP out of its stagnation and make it more interesting for people to jump in and help again. FOP's gona live! :-) Jeremias Maerki I can understand that some sponsors may be sensitive to divulging such information, for at least two reasons. Firstly, the treat of being inundated with begging letters, and secondly, the possibility that they might be upsetting their own business partners. Before you took up the sponsorship offer, you mentioned to me that it was on the cards, which I appreciated. I assume you told others as well. Targeted sponsorship is potentially extremely disruptive to a group, and it seems to me that the process must be as open as possible. If it can't be as open as the code, it should be nearly so. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: The space resolution examples
It could very well be that I got something wrong about spaces. Unfortunately, I don't have much time right now to dive into this, so it has to wait until next week. But we should probably start by analyzing the spec to see what the real behaviour should be. Please update the Wiki if you find the right references. Thanks and sorry for not immediately addressing it. On 30.09.2005 08:50:22 Simon Pepping wrote: Hi, I have a problem with a number of examples on the Wike space resolution examples page. I wonder if I have a major misunderstanding. In general, I have a different idea about the retain condition. Retained spaces do not appear between areas returned by the FO; all spaces appear before or after all areas returned by the FO. This is different from retained padding and borders. * Example 0 IMHO it should be: Here we look at the case where a break happens before before break. * Example 1 IMHO it should be: The break after first line does not produce a 10pt space because the space is conditional. and my element list is (case 'All spaces are conditional'): box w=lh for first line penalty w=0 p=0 for the break possibility after first line glue w=10pt for the space in case there is no break box w=lh for before break penalty w=0 p=0 for the break possibility after before break box w=lh for after break * Example 2 My element list is (case 'Only the first space is conditional'): box w=lh for first block penalty w=0 p=0 for the break possibility box w=0 penalty p=INF aux glue w=10pt for space-before box w=lh for before break penalty w=0 p=0 for the break possibility after before break box w=lh for after break * Example 3 Break between the blocks: Both space specifiers are conditional, and are suppressed due to rule 1 in 4.3.1. My element list is (case 'All spaces are conditional'): box w=lh for first block penalty w=0 p=0 for the break possibility glue w=10pt y=0 z=0 box w=lh for second block * Example 4 Break between the blocks: The first space specifier is retained, the second is conditional, and is suppressed. My element list is (case 'Only the second space is conditional'): box w=lh for first block glue w=10pt y=0 z=0 penalty w=0 p=0 for the break possibility box w=lh for second block * Example 5 Break between the blocks: Both space specifiers are retained. That means that with a break we have more space than without a break, and we need a negative glue (glue #2) to compensate this. My element list is (the full case glue #1 - penalty - glue #2 - box - PENALTY - glue #3): box w=lh for first block glue w=10pt y=0 z=0 penalty w=0 p=0 for the break possibility glue w=-10pt y=0 z=0 box w=0 penalty w=0 p=INF glue w=10pt y=0 z=0 box w=lh for second block * Example 8 The space-before of the block with second line is conditional, and therefore is suppressed. My element list is (case 'All spaces are conditional'): box w=lh for first line aux glue w=6pt y=0 z=0 box w=lh for second line Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl Jeremias Maerki
Space resolution implementation and break possibility building
Hi, Some thoughts about the space resolution implementation notes. I believe that borders and padding are not unresolvable elements. They can always be determined by their LM because they do not interact with the borders and padding of other LMs. They do influence space resolution. They act as fences and break space sequences into several separate stacking constraints. This can be taken into account by the Space Resolver if the Knuth elements for the borders and padding make it clear that they are a fence to stacking constraints. And some (perhaps irrelevant) observations about break possibility building. The situation regarding retained borders and padding resembles the situation of table headers and footers closely. Nevertheless, Jeremias presents a Knuth element list which is simpler: penalty(pb-after) glue(-pb-before) box PENALTY glue(pb-before) According to the table header/footer treatment, the list would be: penalty(pb-before + pb-after) at each break possibility, representing the border and padding on the page before the break. glue(pb-before + pb-after) at the end, representing the single occurrence of the border and padding that occurs without any break. This solution would be especially more complicated for borders and paddings of nested blocks. I am wondering why the element list for borders and paddings can be constructed in a simpler way than that for table headers/footers. I think it is due to the fact that glue can be undone, while boxes cannot. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Sponsorship
On Fri, Sep 30, 2005 at 08:27:45AM +0100, Peter B. West wrote: Jeremias Maerki wrote: On 29.09.2005 11:58:57 Peter B. West wrote: I can understand that some sponsors may be sensitive to divulging such information, for at least two reasons. Firstly, the treat of being inundated with begging letters, and secondly, the possibility that they might be upsetting their own business partners. Before you took up the sponsorship offer, you mentioned to me that it was on the cards, which I appreciated. I assume you told others as well. Targeted sponsorship is potentially extremely disruptive to a group, and it seems to me that the process must be as open as possible. If it can't be as open as the code, it should be nearly so. Do you mean that such a sponsorship changes the relations within the group? It certainly does. I feel that Jeremias has done an admirable job in managing the relations within the group, and in balancing his full time input in FOP with the more limited input of other group members. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Sponsorship
On Fri, 30 Sep 2005 03:27 pm, Peter B. West wrote: Jeremias Maerki wrote: On 29.09.2005 11:58:57 Peter B. West wrote: Jeremias, I meant to ask you when you mentioned your sponsor; who is it? I'm not at liberty to disclose that at this point. I'm sure they're happy with the work you've put in. Yes, they are. We've already achieved one of the major goals: To bring FOP out of its stagnation and make it more interesting for people to jump in and help again. FOP's gona live! :-) Jeremias Maerki I can understand that some sponsors may be sensitive to divulging such information, for at least two reasons. Firstly, the treat of being inundated with begging letters, and secondly, the possibility that they might be upsetting their own business partners. Before you took up the sponsorship offer, you mentioned to me that it was on the cards, which I appreciated. I assume you told others as well. Targeted sponsorship is potentially extremely disruptive to a group, and it seems to me that the process must be as open as possible. If it can't be as open as the code, it should be nearly so. I always thought in these open source projects you are judged by your peers on the basis of what you do and not on who pays your bills. Peter Manuel
Re: Maintainability
Thanks to Luca for his (perhaps entirely co-incidental) posting to the Wiki. Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Maintainability
Peter B. West wrote: Thanks to Luca for his (perhaps entirely co-incidental) posting to the Wiki. Well, not entirely co-incidental! :-) I started writing the page some time ago, but never found the time to finish it: your message made me think I really couldn't put this off any longer, so I added a few things and posted what was ready. I'd try and add the missing parts as soon as possible. Comments, questions, suggestions, and especially additions :-) are most welcome! Regards Luca
Re: Maintainability
Luca Furini wrote: Peter B. West wrote: Thanks to Luca for his (perhaps entirely co-incidental) posting to the Wiki. Well, not entirely co-incidental! :-) I started writing the page some time ago, but never found the time to finish it: your message made me think I really couldn't put this off any longer, so I added a few things and posted what was ready. I'd try and add the missing parts as soon as possible. Comments, questions, suggestions, and especially additions :-) are most welcome! Regards Luca Luca, There seem to be some misapprehensions about what you are attempting; perhaps they are mine, so please clarify this. As I understand it, the mature, well-documented technology is the line-breaking, as in Breaking Lines Into Paragraphs. Using this model for page-breaking is something that has been speculated about, in particular by Plass. However, in implementing this, you and the others are breaking new ground. If this is the case, then it is quite inaccurate to describe the page-breaking as mature, well-understood, well-documented and well-behaved technology. Is that fair? Peter -- Peter B. West http://cv.pbw.id.au/ Folio http://defoe.sourceforge.net/folio/ smime.p7s Description: S/MIME Cryptographic Signature
Re: Maintainability
On Fri, 30 Sep 2005 07:00 pm, Peter B. West wrote: Luca Furini wrote: Peter B. West wrote: Thanks to Luca for his (perhaps entirely co-incidental) posting to snip/ Luca, There seem to be some misapprehensions about what you are attempting; perhaps they are mine, so please clarify this. As I understand it, the mature, well-documented technology is the line-breaking, as in Breaking Lines Into Paragraphs. Using this model for page-breaking is something that has been speculated about, in particular by Plass. However, in implementing this, you and the others are breaking new ground. If this is the case, then it is quite inaccurate to describe the page-breaking as mature, well-understood, well-documented and well-behaved technology. Is that fair? Actually in the Breaking Paragraphs into Lines paper Knuth explicitly mentions that the Box-Glue-Penalty model applies equally well in the vertical direction. Peter Manuel
Re: Maintainability
Peter B. West wrote: There seem to be some misapprehensions about what you are attempting; perhaps they are mine, so please clarify this. As I understand it, the mature, well-documented technology is the line-breaking, as in Breaking Lines Into Paragraphs. Using this model for page-breaking is something that has been speculated about, in particular by Plass. However, in implementing this, you and the others are breaking new ground. If this is the case, then it is quite inaccurate to describe the page-breaking as mature, well-understood, well-documented and well-behaved technology. Is that fair? As Manuel has quickly answered, the box-penalty-glue model can be applied to both line breaking and page breaking, and this is already clearly stated in the cited article. In the Texbook you can find out that horizontal lists (representing the content of paragraphs) and vertical lists (representing content in the block progression direction) are made of the same elements: boxes, glues and penalties. So, I think we can surely state that the model suits the page breaking problem too. What Tex does not is performing Knuth's breaking algorithm in order to produce page breaks: it performs instead a simpler algorithm. But this is due to the resource limits existing at the moment when Tex was devised, and in the cited paper Knuth explicitly says so. The page breaking problem has some more difficulties, concerning objects whose placement does not follow the main flow, for example floating figures; in this case, the difficulty is the other side of freedom (the position of these objects has little constraints) and comes from trying to place them in the best possible way, which could lead to high computational complexity: should this be too much, it would be enough to use a simpler strategy instead, for example placing them in the first page where they fit, and the problem would be solved. So, I think we can say that the algorithm can be applied without any concern to page breaking too. Regards Lucat
RE: rtf-external-graphics
Did you meet any difficulties?
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 29, 2005 12:33 AM
To: fop-dev@xmlgraphics.apache.org
Cc: Danila Ermakov
Subject: Re: rtf-external-graphics
I'll look into it tomorrow. Peter's last change for external-graphics in
RTF made me wonder if we shouldn't actually change the whole code there
and use the image library wrappers the normal renderers use. Like this
we could use the image cache, more image formats and URI resolution the
same way as for the other output formats.
On 28.09.2005 17:10:23 Sergey Simonchik wrote:
Hi,
After patch of Peter Herweg, adding support of external-graphics in Rtf
(25.09.2005, revision 291449) some problems are still unresolved.
I'm talking about using url's in src attribute of fo:external-graphic
tag.
Take a look at fo-file below:
...
fo:flow flow-name=xsl-region-body
fo:block start-indent=12pt space-before=3pt
fo:external-graphic src=url('01.jpg')/
/fo:block
/fo:flow
...
Rtf renderer produced file 01a.rtf (see in attach).
After changing in file RTFHandler.java string
newGraphic.setURL(eg.getSrc());
to string
newGraphic.setURL(eg.getURL());
Rtf renderer produced another file 01b.rtf (in attach too).
File 01b.rtf seems to be correct whether 01a.rtf is not.
What do you think about it?
Thanks for attention!
Jeremias Maerki
