Hi Vincent, I just read the bug report discussion. Most points I either agree with you or don't know enough to disagree (the relevance of 'script', for example). So, FOP is essentially correct and shouldn't change its default behaviour. Only an extension could help.
> > More seriously, you could take it the other way around, and find users who > > wouldn't be happy at all to see FOP suddenly break their texts at arbitrary > > places, and would rather be warned when such situations are occuring, so > > that > > they can re-work their contents. >From my experience, an overflow warning by itself hardly helps. During development I get PAGES of overflow warnings. 99% of them are, while not nice, ignoreable. I can't test every possible data combination. So sometimes the user might get an overflow. The debug output is not transfered to the user, only the finished PDF is. And here (for me) it's far easier to notice an additional line with only one letter than a full line with the last letter overwriting the first letter of the next cell. Yes, an upstream solution would be better, but we are talking about cases, where the only upstream solution would be a zws between each two characters. I don't know if anybody analyzed the content-to-markup-ratio of fo-files before, but I have fo-files of 220MB, let's assume 10% is real text, so I'd insert 20 million zws and actually need maybe two of them. 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: Dienstag, 6. Oktober 2009 12:27 An: [email protected] Betreff: Re: force wordbreak Hi, Georg Datterl wrote: > Hi Chris, > > I was afraid the specification was to blame. One could implement an > extension, put it on flow, maybe even page-sequence and make it inheritable. > So it would not break existing code. That would be quite easy. Only I don't > know how much work the changes in the actual line-breaking algorithmus would > be. See following bug report for a discussion of the issue: https://issues.apache.org/bugzilla/show_bug.cgi?id=43474 As a summary: I don't think anything should be done in FOP. This issue is better handled upstream (usually by inserting zero-width spaces "at the right places", which sometimes can be properly done only by a human being). If the URL doesn't fit in a table cell, then don't put it in a table. Or increase the width of the table cell accordingly. URL quickly become unreadable when they are broken anyway. Vincent > Mit freundlichen Grüßen > > 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: Chris Bowditch [mailto:[email protected]] > Gesendet: Dienstag, 6. Oktober 2009 11:39 > An: [email protected] > Betreff: Re: AW: force wordbreak > > Georg Datterl wrote: >> Hi J, > > Hi Georg, > >> >> I just wondered. If FOP doesn't find a break possibility, the text is >> printed outside of the area. In table cells, the text is printed into the >> next cell. Does anybody need this? Wouldn't it be better to break anyway if >> the outer areas ipd is reached? And if I WANT to write into the next cell, I >> could always use keep-together.within-line="always"... > > or wrap-option="no-wrap" > > I think the reason this is not done as you suggest is because the > specification mandates the current behaviour. However, I concur with you. It > would be more beneficial if the behaviour was user friendly and either > wrapped or not the text based on the wrap-option property. > > Thanks, > > Chris > >> 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: J.Pietschmann [mailto:[email protected]] >> Gesendet: Montag, 5. Oktober 2009 23:12 >> An: [email protected] >> Betreff: Re: force wordbreak >> >> On 05.10.2009 14:22, Georg Datterl wrote: >>> Probably the only thing you can do is insert zero-width spaces. >> Hmm, I've pondered crafting hyphenation patterns for URLs for some time. >> Q: Where should breaks in an URL occur? Only after '/' and '&'? >> This may leave URLs with large fragment Ids unbroken, which are >> unfortunately quite common. >> >> Once the patterns are there, >> <fo:block language="url" hyphenation-character="&zws;">... >> should work nicely. OTOH, hyphenation properties are block level only, which >> will have the side effect of not hyphenating natural language around the URL >> ... >> >> J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
