Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
On 25.11.2008 21:55:49 Adrian Cumiskey wrote: snip/ OTOH, I feel compelled to mention that attempting to kill a raised, perfectly legitimate issue in an unreasonable way (by taking it to be a personal offense), may alienate some people... From a diplomatic viewpoint, not a very sound move to make right before you decide to launch a vote. :/ I wasn't in anyway trying to kill the raised issue, I just chose the option that I believed at the time would involve the least amount of change and provide the quickest solution to the problem. I believe now that all interested parties should feel satisfied with the concluding result to issue raised. I think that's the problem: you chose, instead of discussing ideas and plans that may be non-trivial or controversial on the mailing list. My wish is that you try more to detect things like that. Sometimes it's just a matter of dropping a mail on the list saying you wish to change this and that because of X or Y. Even if noone responds (which is unlikely), you have at least lazy consensus. Apparently, my wording was too strong which was only to get you to listen. This is probably an expression of my inability to communicate what I was trying to get across. For that I apologize and I will keep trying to keep my tone in check. Jeremias Maerki
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Adrian Cumiskey wrote: Hi Adrian, Hi Andreas, 2008/11/25 Andreas Delmelle [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Adrian, just a small FWIW: Chris has drawn the right conclusion, I think. No need to take any of the questions/remarks personal (even though I understand this is difficult after the time you've spent on perfecting the code in that branch). Its not been so much perfecting, its been more a matter of trying to clean up the mess that I inherited, trying to eliminate as much copy/paste, hardcoded definitions as possible and reuse existing functionality where possible without breaking anything. This was confounded by the strict binary data structure of AFP, extensive and somewhat ambiguous documentation, and generally poor availability of datastream analysis tools. and your efforts are appreciated even though our questions may make us seem ungrateful at times :) OTOH, I feel compelled to mention that attempting to kill a raised, perfectly legitimate issue in an unreasonable way (by taking it to be a personal offense), may alienate some people... From a diplomatic viewpoint, not a very sound move to make right before you decide to launch a vote. :/ I wasn't in anyway trying to kill the raised issue, I just chose the option that I believed at the time would involve the least amount of change and provide the quickest solution to the problem. I believe now that all interested parties should feel satisfied with the concluding result to issue raised. Yes I am now very happy and pleased to give my +1 to this vote. Thanks, Chris
DO NOT REPLY [Bug 45097] Questionable white-space-treatment behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=45097 --- Comment #15 from Vincent Hennebert [EMAIL PROTECTED] 2008-11-26 03:28:18 PST --- (In reply to comment #14) (In reply to comment #12) Sorry to chime in so late... Based on my novice analysis, it appears the various KnuthElements provide the following purposes: snip / Entirely correct interpretation. A box is never a break-possibility, unless when preceded by a penalty indicating one. Glues are always a break-possibility, unless when preceded by a penalty prohibiting one. That's the general idea. I'm afraid this is wrong. You can break only at two places: - a penalty element whose penalty value is not infinite; then the width of the penalty must be taken into account. - a glue element that's immediately preceded by a box; then you discard the glue's length, shrink and stretch. Also, when an element is chosen as a breaking point, all the following glue and penalty elements (if any) are discarded up to the next box element. The presence of aux. box w=0 at places in the sequence is meant to prevent the triggering of that mechanism. See section “Breaking Rules” at the following page: http://wiki.apache.org/xmlgraphics-fop/KnuthsModel snip/ For 2), I'm thinking of very extreme (and highly unusual) cases, where it becomes necessary to choose 'a' break, but the choice is between white-space characters only. If white-space treatment is preserve, a portion of white-space should, strictly speaking, be pushed to the next line, and influence alignment there... but ideally, if it all fits on one line, that possibility should obviously be preferred above all else. This is probably the biggest issue. This may require to handle a sequence of white spaces in its whole instead of each character individually. Sorry, I don't have enough energy ATM to look at this issue into more details. Being sure that every combination of white space options (white-space-treatment, white-space-collapse, linefeed-treatment...) is handled correctly requires an extensive study. Vincent -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #15 from Vincent Hennebert [EMAIL PROTECTED] 2008-11-26 03:59:32 PST --- Hi, I'm sorry to chime in so late but I don't think there is anything to do on FOP's side WRT this issue. If there is no opportunity to break inside the word then there's nothing FOP can do. The wrap-option property is meant to trigger the line-breaking mechanism in its usual accepted meaning; that is, break between words or at hyphenation points inside them, not at every letter if available space is abnormally low, or the word abnormally big. At least, that's my understanding of this property. In my opinion, this issue must be handled upstream. That is, zero-width space characters (U+200B) must be introduced at applicable places inside the word to provide FOP with more break opportunities. But I don't think this is FOP's responsibility to do that. See also the following FAQ entry: http://xmlgraphics.apache.org/fop/faq.html#cells-overflow Vincent (In reply to comment #14) (In reply to comment #11) I created a patch working with the latest trunk version. It's similar to the last patch. But there were some further problems which are fixed, list-item-labels were always wrapped, and the algorithm for choosing the correct break position was not correct inside tables. I think this functionality is very important for a lot of users as there is even a faq entry. Good to see this being picked up. I'm in the process of reviewing the patch, and already have some questions/considerations: I'm not sure I like the additional reference to ListItemLabel in TextLayoutManager. The TextLM should deal with text (FOText), and if necessary, the ancestor ListItemContentLM should pass the necessary info (a flag in the LayoutContext?) down to prevent the label from being broken. Right now, a dev would have to look at the TextLM to find out why a list-item-label is never broken...? I'd rather see an accompanying change to the list-related LMs to account for this. I'll see if I can come up with a polished alternative, to show what I mean. As to the cause for the fact that the label is always broken: this is probably because the area gets its inline-progression-dimension from the content, so when the element-list is first constructed, the reference-ipd (line-width) will still be zero... I agree that not breaking would be the preferred behavior. If a user really needs this effect, he/she can always resort to a two-column table. The changes to LineLM: Are they necessary due to the changes to TextLM, or is that a separate issue? Just asking, since the javadoc for the first added private method seems to indicate that the original expression could return a wrong result regardless of the value of wrap-option (?) The same style issues as Chris mentioned in #42374 put aside, your patch has given me some ideas, which I'll start trying out real soon. Thanks for your input so far! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
Jeremias Maerki wrote: On 25.11.2008 21:55:49 Adrian Cumiskey wrote: snip/ OTOH, I feel compelled to mention that attempting to kill a raised, perfectly legitimate issue in an unreasonable way (by taking it to be a personal offense), may alienate some people... From a diplomatic viewpoint, not a very sound move to make right before you decide to launch a vote. :/ I wasn't in anyway trying to kill the raised issue, I just chose the option that I believed at the time would involve the least amount of change and provide the quickest solution to the problem. I believe now that all interested parties should feel satisfied with the concluding result to issue raised. I think that's the problem: you chose, instead of discussing ideas and plans that may be non-trivial or controversial on the mailing list. My wish is that you try more to detect things like that. Sometimes it's just a matter of dropping a mail on the list saying you wish to change this and that because of X or Y. Even if noone responds (which is unlikely), you have at least lazy consensus. At the time I did not see it as a big issue, but now I am more aware that something which may not seem a like a biggie to me, may cause a big itch to someone else. So I'll try to keep this consideration more in mind going forward. Apparently, my wording was too strong which was only to get you to listen. This is probably an expression of my inability to communicate what I was trying to get across. For that I apologize and I will keep trying to keep my tone in check. Apology accepted, lets move on from this now and try to get back to some software development. Adrian.
Re: [VOTE] Merge Temp_AFPGOCAResources branch into trunk
+1 from me! Thanks for your hard work! Clay On 11/26/08, Chris Bowditch [EMAIL PROTECTED] wrote: Adrian Cumiskey wrote: Hi Adrian, Hi Andreas, 2008/11/25 Andreas Delmelle [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Adrian, just a small FWIW: Chris has drawn the right conclusion, I think. No need to take any of the questions/remarks personal (even though I understand this is difficult after the time you've spent on perfecting the code in that branch). Its not been so much perfecting, its been more a matter of trying to clean up the mess that I inherited, trying to eliminate as much copy/paste, hardcoded definitions as possible and reuse existing functionality where possible without breaking anything. This was confounded by the strict binary data structure of AFP, extensive and somewhat ambiguous documentation, and generally poor availability of datastream analysis tools. and your efforts are appreciated even though our questions may make us seem ungrateful at times :) OTOH, I feel compelled to mention that attempting to kill a raised, perfectly legitimate issue in an unreasonable way (by taking it to be a personal offense), may alienate some people... From a diplomatic viewpoint, not a very sound move to make right before you decide to launch a vote. :/ I wasn't in anyway trying to kill the raised issue, I just chose the option that I believed at the time would involve the least amount of change and provide the quickest solution to the problem. I believe now that all interested parties should feel satisfied with the concluding result to issue raised. Yes I am now very happy and pleased to give my +1 to this vote. Thanks, Chris -- Regards, The Web Maestro -- [EMAIL PROTECTED] - http://ourlil.com/ My religion is simple. My religion is kindness. - HH The 14th Dalai Lama of Tibet
AW: empty columns on multi-column-page
Hi Vincent, I started to fool around a bit with the FOP source code and your suggestion: I've just had a quick look and there seems to be almost nothing to do on the layout side (which is good news). You just have to go on l.111 of org.apache.fop.layoutmgr.PageBreaker (handleSpanChange method) and replace the assignment appropriately. Instead of: needColumnBalancing = (childLC.getNextSpan() == Constants.EN_ALL); something like needColumnBalancing = (childLC.getNextSpan() == Constants.EN_ALL) childLC.nextHasFoxBalancingOption(); Simply setting false already gave me the desirable result on a small example. Indeed, it worked on a small example, but a bigger example gave me an unexpected heart attack. If the wide block is in the first column, the result looks like I expected it, but then I had a wide block in the second column and instead of moving to the next page, I got balancing again: header AAA CCC AAA CCC AAA CCC BBB BBB BBB DDD DDD DDD footer I guess, the next step is somewhere in Phase 3, but I've yet to understand the effect of needColumnBalancing there. Any hints? ;-) P.S.: For those who don't read fop-user and don't know what I want to do: I have a two-column layout, but when a wide block (span=all) is encountered, I only want to fill one column above the block (on this page). Below the block both columns may be filled again. Regards, Georg Datterl -- Kontakt -- Georg Datterl Geneon media solutions gmbh Gutenstetter Straße 8a 90449 Nürnberg HRB Nürnberg: 17193 Geschäftsführer: Yong-Harry Steiert Tel.: 0911/36 78 88 - 26 Fax: 0911/36 78 88 - 20 www.geneon.de Weitere Mitglieder der Willmy MediaGroup: IRS Integrated Realization Services GmbH:www.irs-nbg.de Willmy PrintMedia GmbH:www.willmy.de Willmy Consult Content GmbH: www.willmycc.de -Ursprüngliche Nachricht- Von: Vincent Hennebert [mailto:[EMAIL PROTECTED] Gesendet: Montag, 27. Oktober 2008 12:57 An: [EMAIL PROTECTED] Betreff: Re: empty columns on multi-column-page Hi Georg, Georg Datterl wrote: Hello Vincent, Well, most of the time even I would use the balancing algorithm, but not in all cases. I guess I could implement a kind of fox-useBalancer=false for this cases, but even that would not make Block C (see below) possible. Well, I think it would. Basically the option would be do not balance columns before a block that spans the whole page. So, on your example below, the bottom of page 1 is reached before block E is encountered, so columns are balanced. On page 2, block E is encountered so column balancing is disabled, then re-enabled after block E until the bottom of the page, etc. Actually this would be more efficient since there would be no need to re-typeset the content, in order to balance columns before a spanning block, as I believe it's done ATM. Might be a useful extension. So it would be an extension for the page, not for the block. Either for simple-page-master or (probably better) for region-body, if I understand you correctly. Oh, you're right actually, this can well be an extension for the spanning block. That would provide more flexibility since it would be possible to individually customize the behaviour. If the option were set on the region-body it would be the same for all spanning blocks. Do you think that's possible and how much work would it be? Mind, I'm not asking you to implement it, but if you say it's possible and you could do it in a day, I guess I might be able to do it in a reasonable time (actually, not me, but a colleague of mine who actually knows his way around the fop source code, I hope). I've just had a quick look and there seems to be almost nothing to do on the layout side (which is good news). You just have to go on l.111 of org.apache.fop.layoutmgr.PageBreaker (handleSpanChange method) and replace the assignment appropriately. Instead of: needColumnBalancing = (childLC.getNextSpan() == Constants.EN_ALL); something like needColumnBalancing = (childLC.getNextSpan() == Constants.EN_ALL) childLC.nextHasFoxBalancingOption(); Simply setting false already gave me the desirable result on a small example. The difficulty is to make the necessary wiring in order to communicate the value of the option from the FO tree to the layout engine. I can't really help you on that matter, sorry, but you may want to have a look at how the fox:orphan-content-limit is implemented and do something similar: http://xmlgraphics.apache.org/fop/trunk/extensions.html#widow-orphan-content-limit If you decide to give it a go then switch to the fop-dev mailing list for any question: http://xmlgraphics.apache.org/fop/dev/index.html#mail-fop-dev snip/ Thanks, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail:
Re: Remove FAQ Entries Related to 0.20.5
I've done an experiment today to get a feel how much work it would be to split up the site from the product docs. It's doable but a lot of work with rather little benefit, it seems. I guess I'll bury the idea for now. On 19.11.2008 14:02:28 Jeremias Maerki wrote: Hi Vincent, well, I haven't thought this through, yet. I've just let ideas bubble up. I agree that migrating the development tab over to the Wiki is probably a good idea since the most current stuff is there anyway. Cleaning the stale stuff is long overdue. It only confuses and misleads people. As for the project vs. product/release separation, I meant: - project: Welcome, News, Download, how to get help etc. - product/release: The actual product documentation (i.e. the manual) plus additional resources (FAQ, changes, known issues...) At the moment we bundle the product documentation for 0.94 with the release of 0.95 which is kind of strange. For the website, it makes sense to have documentation for the last couple of releases plus trunk. What's bugging me is copying the whole release folder and then updating all links. If we had a separate project site, we could use the .htaccess redirects to link to the latest release rather than replacing version numbers (nearly) everywhere. In some places we might be able to work with XInclude if necessary. Having a separate product setup might also faciliate generating a site PDF that becomes the FOP manual. I'm looking for ways to simplify our release checklist. Maybe I'll just need one of those cold gray winter Sundays to do an experiment locally. If it works, we can actually implement it. As for migrating to a Wiki entirely: Some projects use Confluence to do something like that. But I have no idea how good this works and if we can still do cool things like auto-generate content and RSS feeds from XML files in our repo. Furthermore, I'm not a fan of using commercial tools for infrastructure of an open source project. On 19.11.2008 12:25:28 Vincent Hennebert wrote: Hi Jeremias, Jeremias Maerki wrote: Good idea. Going further, we could think about splitting the FAQ into a project part and a product part. To make the release procedures easier we might want to split the website into a project website and a product/release website. What we have now just takes too much work which is at least partly what keeps us from releasing more often (which we should do). Just an idea (I would still need to find time to put action behing words, though). I’m not sure of what you mean by project and product/release? AFAICT the sections of the website we update before a release are the sections relevant to the product, so we would still have roughly the same amount of work to do. As for myself, I didn’t even bother to update the ‘Development’ tab, which is mostly out-of-date now, when I took care of releases. Now there is also the wiki that I’d consider to be the ‘project’ website. I think it would make sense to move as many things as possible there, since it’s easier to manage, update, modify, etc. For us as well as for contributors, who wouldn’t have to look for source files hidden deep inside the source tree, submit patches that then require review, commit, build, publish, wait a couple of hours for changes to appear, etc. On a more extreme side, the whole website might also be converted into a wiki... On 18.11.2008 12:14:41 Vincent Hennebert wrote: Guys, What do you think of removing entries in the FAQ section that are specific to 0.20.5 and earlier versions? This would make it shorter, so less likely to scare people away, and in the same time easier for them to find the answer to their question. Plus it would stress the fact that we no longer support 0.20.5. My 2 cents, Vincent Jeremias Maerki Jeremias Maerki
DO NOT REPLY [Bug 45097] Questionable white-space-treatment behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=45097 --- Comment #16 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-26 11:10:50 PST --- (In reply to comment #15) snip / Thanks for the rectification, although I wasn't really wrong. At most, not accurate enough. ;-P snip/ For 2), I'm thinking of very extreme (and highly unusual) cases, where it becomes necessary to choose 'a' break, but the choice is between white-space characters only. If white-space treatment is preserve, a portion of white-space should, strictly speaking, be pushed to the next line, and influence alignment there... but ideally, if it all fits on one line, that possibility should obviously be preferred above all else. This is probably the biggest issue. This may require to handle a sequence of white spaces in its whole instead of each character individually. Sorry, I don't have enough energy ATM to look at this issue into more details. Being sure that every combination of white space options (white-space-treatment, white-space-collapse, linefeed-treatment...) is handled correctly requires an extensive study. I was thinking about introducing a special type of auxiliary glue, with the possibility to break it in two at a position that is not fixed at the time the element is generated. (more like a combination of two glues, whose combined width is known, but not the width of the two individual elements.) The LineLM would then treat this as a whole, but not an unbreakable whole, see how big a portion it can fit on one line, and insert an auxiliary box for the remaining width (rather than /always/ adding that auxiliary box in the TextLM when white-space-treatment='preserve'). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 43474] [PATCH] wrap-option=wrap doesn't work
https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 --- Comment #16 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-26 11:30:42 PST --- (In reply to comment #15) I'm sorry to chime in so late but I don't think there is anything to do on FOP's side WRT this issue. On the one hand, I agree. I have mentioned this already in the past: wrap-option=wrap does not include an /obligation/ to perform line-wrapping. If there is no opportunity to break inside the word then there's nothing FOP can do. Wrong. At least, slightly unfortunate choice of words: FOP /can/ definitely do /something/ in this case. The wrap-option property is meant to trigger the line-breaking mechanism in its usual accepted meaning; that is, break between words or at hyphenation points inside them, not at every letter if available space is abnormally low, or the word abnormally big. At least, that's my understanding of this property. IIC, there's a subtle difference between line-WRAPPING and line-BREAKING. Line-wrapping being the more 'blind' of the two, if you will (simply wrap to fit the text into the available space). The Recommendation remains vague in this respect (and purposely so, I think). It does not prescribe /how/ the text should be wrapped or broken. We have decided to follow Unicode, but ultimately, we always have the last word. That is: if we choose to provide an additional fallback mechanism, there is no relevant specification that makes this wrong. In my opinion, this issue must be handled upstream. That is, zero-width space characters (U+200B) must be introduced at applicable places inside the word to provide FOP with more break opportunities. A legitimate option, but not always as easily done as it said. To get the effect of real dynamic content-wrapping (fit as many characters on the line as you can), you would force the user to insert a ZWSP in between every two characters (either that or they should make a choice of every so-many characters). But I don't think this is FOP's responsibility to do that. See also the following FAQ entry: http://xmlgraphics.apache.org/fop/faq.html#cells-overflow Maybe not, but it would mean a big relief for many users, I think, if FOP would take this responsibility, even if it is not mandated... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45097] Questionable white-space-treatment behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=45097 --- Comment #17 from Andreas L. Delmelle [EMAIL PROTECTED] 2008-11-26 12:34:10 PST --- (In reply to comment #16) (In reply to comment #15) This is probably the biggest issue. This may require to handle a sequence of white spaces in its whole instead of each character individually. Sorry, I don't have enough energy ATM to look at this issue into more details. Being sure that every combination of white space options (white-space-treatment, white-space-collapse, linefeed-treatment...) is handled correctly requires an extensive study. I was thinking about introducing a special type of auxiliary glue, ... Or maybe even, we could benefit from a space-resolution pass in line-layout too. Replace the white-space sequences by one unresolved SpaceElement, and resolve those in the LineLM, at the end of collecting the inline elements for a paragraph. That would probably be the most comprehensive approach, since it could then be folded into space-start/space-end resolution (currently non-functional), and it would make it much easier to detect sequences of consecutive preserved white-space characters across FO boundaries... -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 45097] Questionable white-space-treatment behavior
https://issues.apache.org/bugzilla/show_bug.cgi?id=45097 --- Comment #18 from Sean Griffin [EMAIL PROTECTED] 2008-11-26 12:55:58 PST --- I think I know enough now to know that this issue is clearly over my head :) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
