Re: Change bars status
Dear All, On 2015-07-19 Jan Tosovsky wrote: > On 2015-07-18 Stephan Thesing wrote: > > I have a local patch without respecting writing direction that also > > produces correct results for the example fo sent earlier in this > > thread > > I like your update as it doesn't touch FOUserAgent (change bars are > stacked in PageSequence) and it doesn't pollute various area classes > with that BiDi handling. > > I've incorporated these changes into my clone. For LR writing direction > it still passes all my tests. > > I'll submit it together with further details to the original JIRA > issue. I commited these changes in July: https://issues.apache.org/jira/browse/FOP-1760 (together with layout tests and comments) Would anybody mind reviewing it? Thanks, Jan
RE: Re: Change bars status
Hi Stephan, On 2015-07-18 Stephan Thesing wrote: > I have a local patch without respecting writing direction that also > produces correct results for the example fo sent earlier in this thread I like your update as it doesn't touch FOUserAgent (change bars are stacked in PageSequence) and it doesn't pollute various area classes with that BiDi handling. I've incorporated these changes into my clone. For LR writing direction it still passes all my tests. I'll submit it together with further details to the original JIRA issue. Thanks a lot for moving this further! Jan
RE: Re: Change bars status
On 2015-07-18 Stephan Thesing wrote: > I have a local patch without respecting writing direction that also > produces correct results wow! > I can provide the patch later this day if there is interest Uff :-) I've finalized layout tests and was about submitting a new patch :-) My current version handles placement depending on writing direction except inline elements in RL mode. Any improvement in this area is more than welcome. I'll submit my changes anyway, it fixes other corner cases. You can then grab it, review and finalize it for merging :-) Thanks, Jan <>
Re: Change bars status
Hi Stephan Thanks for chiming in! > On 18 Jul 2015, at 11:58, Stephan Thesing wrote: > > just a few remarks for the changebars: > - the patch was done when bidi support was starting. Actually, the first > patch contained already provisions for the writing direction to place > the bars at the correct edges. That support was later removed, as bidi > support was not working fully working. > - I have a local patch without respecting writing direction that also > produces correct results for the example fo sent earlier in this thread > - I can provide the patch later this day if there is interest Sure, if you can attach it in JIRA or make it otherwise available, that would be much appreciated. Thanks! KR Andreas
Aw: Re: Change bars status
Hello, just a few remarks for the changebars: - the patch was done when bidi support was starting. Actually, the first patch contained already provisions for the writing direction to place the bars at the correct edges. That support was later removed, as bidi support was not working fully working. - I have a local patch without respecting writing direction that also produces correct results for the example fo sent earlier in this thread - I can provide the patch later this day if there is interest Best regards Stephan Gesendet: Samstag, 18. Juli 2015 um 11:38 Uhr Von: "Andreas L. Delmelle" An: fop-dev@xmlgraphics.apache.org Betreff: Re: Change bars status Hi Jan > On 16 Jul 2015, at 00:23, Jan Tosovsky wrote: > It is actually BidiResolver.reorder() method which returns unexpected order. > It also explains why a period is placed at the beginning of the second line > even in non-change bars source. Aha! IIC, the patch predates the implementation of Unicode Bidi resolution, so that may explain a few things. > > > Is it a known issue or should I file a bug? Not entirely sure. Seems like it may be related to FOP-2290[*], although that one explicitly mentions empty blocks. If you are convinced it is a totally different one, feel free to log a new issue. Thanks! [*] https://issues.apache.org/jira/browse/FOP-2290 KR Andreas
Re: Change bars status
Hi Jan > On 16 Jul 2015, at 00:23, Jan Tosovsky wrote: > It is actually BidiResolver.reorder() method which returns unexpected order. > It also explains why a period is placed at the beginning of the second line > even in non-change bars source. Aha! IIC, the patch predates the implementation of Unicode Bidi resolution, so that may explain a few things. > > > Is it a known issue or should I file a bug? Not entirely sure. Seems like it may be related to FOP-2290[*], although that one explicitly mentions empty blocks. If you are convinced it is a totally different one, feel free to log a new issue. Thanks! [*] https://issues.apache.org/jira/browse/FOP-2290 KR Andreas
RE: Change bars status
On 2015-07-15 Jan Tosovsky wrote: > On 2015-07-14 Andreas Delmelle wrote: > > > On 2015-07-14 Jan Tosovsky wrote: > > > > > > Where exactly inline blocks are appended to the list and passed to > > > the flow? > > > > That would be the LayoutManager.addAreas() implementations. > > > > Thanks for the hint, yes, it comes from > TextLayoutManager.addAreas()/addMappingAreas(); > It is actually BidiResolver.reorder() method which returns unexpected order. It also explains why a period is placed at the beginning of the second line even in non-change bars source. All human beings should act towards one .another in a spirit of brotherhood So this order issue seems to be unrelated to the change bars code. My cases just revealed some uncovered corner cases in the step (4) of the mentioned method: // 4. reorder from maximum level to minimum odd level >From this step on the order is incorrect. So I tend to give up fine tuning of change bars for RL writing directions until the above issue is resolved. Is it a known issue or should I file a bug? Thanks, Jan
RE: Change bars status
On 2015-07-14 Andreas Delmelle wrote: > > On 2015-07-14 Jan Tosovsky wrote: > > > > Where exactly inline blocks are appended to the list and passed to > > the flow? > > That would be the LayoutManager.addAreas() implementations. > Thanks for the hint, yes, it comes from TextLayoutManager.addAreas()/addMappingAreas(); I didn't touch the original code here, but most likely some side-effect. I'll investigate later this week. Jan
Re: Change bars status
Hi Jan > On 14 Jul 2015, at 22:40, Jan Tosovsky wrote: > > > Where exactly inline blocks are appended to the list and passed to the flow? That would be the LayoutManager.addAreas() implementations. I am still not familiar enough with the details of the patch, but if I had to guess, it seems like it could be an issue with the Positions generated for/by the LM, such that the PositionIterator is thrown off when adding the areas for the parent block (?) KR Andreas
RE: Change bars status
> https://issues.apache.org/jira/browse/FOP-1760
I am testing the code for RL writing mode I am getting unexpected word order
when words or inline elements are wrapped by change bars ('towards' in
example below).
All human beings should act towards one another in a spirit of
brotherhood.
All human beings should act towards one
.another in a spirit of brotherhood
All human beings should act towards
one another in a spirit of brotherhood.
one towards All human beings should act
.another in a spirit of brotherhood
Blocks/childAreas are ordered incorrectly already here (AbstractRenderer):
protected void renderFlow(NormalFlow flow) {
// the normal flow reference area contains stacked blocks
List blocks = flow.getChildAreas();
if (blocks != null) {
renderBlocks(null, blocks);
}
}
Where exactly inline blocks are appended to the list and passed to the flow?
Thanks, Jan
<>
Re: Change bars status
Hi Jan > On 10 Jul 2015, at 23:05, Jan Tosovsky wrote: > >> https://issues.apache.org/jira/browse/FOP-1760 > > In the original patch there is used Vector for storing ChangeBars > collection. > > http://stackoverflow.com/questions/1386275/why-is-java-vector-class-consider > ed-obsolete-or-deprecated > > I'd suggest replacing it with LinkedList (the order of entries should be > kept to handle nesting properly). Sure, sounds good. > Or is there any reason for using Vector? The only "reason" I can think of is that the creator of the patch was used to using that instead of ArrayList or LinkedList. KR Andreas
RE: Change bars status
> https://issues.apache.org/jira/browse/FOP-1760 In the original patch there is used Vector for storing ChangeBars collection. http://stackoverflow.com/questions/1386275/why-is-java-vector-class-consider ed-obsolete-or-deprecated I'd suggest replacing it with LinkedList (the order of entries should be kept to handle nesting properly). Or is there any reason for using Vector? Thanks, Jan <>
Re: Change bars status
> No real preference here. Your suggestion is OK. > In general, in typesetting, a "lorem ipsum" generator is frequently used to > generate dummy text (for 'simple' Latin scripts, that is). See: > http://www.lipsum.com > > KR > > Andreas Heh... You can get a similar output using the 'Classic Ipsum' setting on this site: http://slipsum.com ...but that's not nearly as much fun... Then there's always: http://buseyipsum.com Web Maestro Clay
Re: Change bars status
Hi Jan Thanks for your efforts so far in getting this moving forward! As to your question: > > Btw, what is preferred dummy text? Currently I use The Universal Declaration > of Human Rights (Article 1). Is it Ok? No real preference here. Your suggestion is OK. In general, in typesetting, a "lorem ipsum" generator is frequently used to generate dummy text (for 'simple' Latin scripts, that is). See: http://www.lipsum.com KR Andreas
RE: Change bars status
On 2015-07-02 Jan Tosovsky wrote: > I've attached the updated patch recently to the related ticket: > https://issues.apache.org/jira/browse/FOP-1760 > > From that time I locally fixed two issues (2 - support for overlapping > bars) and (4 - wrapping table cells). The rest requires the help of > more experienced devs. I've moved forward the rest of issues. Currently I am considering what should be covered by layout tests. My proposal: change-bar-on-inline (solid bar of same thickness in various places of the content) change-bar-on-block (same for block element) change-bar-on-list (same for list) change-bar-on-table (same for various table fragments - cell, rows, headers, tables) change-bar-on-wrapper (same for wrapper element) change-bar-on-overlapped (testing overlapped bars) change-bar-on-mixed change-bar-style (block elements with various bar styles /solid/dashed/dotted/..., colors and widths) change-bar-position (block elements with start/left/end/inset/... position) change-bar-direction (testing position in LR/RL direction) Btw, what is preferred dummy text? Currently I use The Universal Declaration of Human Rights (Article 1). Is it Ok? Thanks, Jan <>
RE: Change bars status
I've attached the updated patch recently to the related ticket: https://issues.apache.org/jira/browse/FOP-1760 >From that time I locally fixed two issues (2 - support for overlapping bars) and (4 - wrapping table cells). The rest requires the help of more experienced devs. Btw, how about creating a dedicated branch and tweaking it separately? Thanks, Jan <>
RE: Change bars status
On 2015-06-08 Andreas Delmelle wrote: > > On 2015-06-07 Jan Tosovsky wrote: > > > I've found some progress on 'change bar' support here > > > > https://issues.apache.org/jira/browse/FOP-1760 > > > > discussed further here: > > > > http://apache-fop.1065347.n5.nabble.com/Change-bars-support-in-FOP- > > td38134.html > > > > I am unsure of the status of this patch, and how difficult it would be > to apply it to the current trunk or the existing branch... Ok, I've tried to 'apply' the last diff to the current trunk now, most of changes are compatible, some had to be tweaked a bit, but now it at least compiles. I'll perform some basic tests later this week. > If you already have the time and the patience to provide something > resembling real-life use cases, that will be much appreciated. I'll try, but I am afraid my real-life cases are IMHO too simple (seeing the impact of this feature to various LMs and related code). Jan <>
Re: Change bars status
Hi Jan > On 07 Jun 2015, at 19:39, Jan Tosovsky wrote: > I've found some progress on 'change bar' support here > > https://issues.apache.org/jira/browse/FOP-1760 > > discussed further here: > > http://apache-fop.1065347.n5.nabble.com/Change-bars-support-in-FOP-td38134.h > tml > > There is mentioned more test cases are required. What exactly should be > tested? I could prepare something to help to move this feature forward. I am unsure of the status of this patch, and how difficult it would be to apply it to the current trunk or the existing branch, but I can tell you that the tests that Glenn was referring to are mainly just a bunch of FO files. Preferably lots of them, exhaustively checking various scenarios. In order to be easily usable as a "layout engine test", those FO files just need to be wrapped into a testcase document, with added assertions about the output. See: http://wiki.apache.org/xmlgraphics-fop/HowToCreateLayoutEngineTests Note: this does require some affinity with the Area Tree XML format in order to get the XPath expressions for the checks correct, so if you do not have time to dive into that, it's OK to leave the checks node empty, or just write what you want to check in there as a comment (TODO). If you already have the time and the patience to provide something resembling real-life use cases, that will be much appreciated. No guarantees about when someone will have time available to pick it up, though... KR Andreas
