Re: Image align and overflow behaviour since complex scripts patch
i would suggest you open an issue, marking this as a regression On Wed, Dec 19, 2012 at 7:40 AM, Robert Meyer wrote: > Hi, > > I have noticed that since the complex scripts change, if you right-align > an image in a cell and it exceeds the bounds of the cell, it will start > expanding in the opposite direction as opposed to staying locked to the > right side. Is this behaviour correct? I have attached two PDF's showing > this with one run on trunk and one using code from before the patch. > > From looking in the code there is now a check on line 352 in > LineLayoutManager.java which checks the difference for a negative value > before its assigned to the startIndent. If it is found to be the case, its > changed to 0 which prevents the content from overrunning the left side. > Although its a bit cryptic, I found the following under the > external-graphic section in the XSL:FO specification which leads me to > believe it should stay locked to the direction assigned by the text-align > property: > > "Once scaled, the reference-area is aligned with respect to the > viewport-area using the *text-align* and *display-align* traits. If it is > too large for the viewport-area, the graphic is aligned as if it would fit > and the *overflow* trait controls the clipping, scroll bars, etc." > > I did also notice that negative start-indent values are allowed under > blocks, but I am not sure if this is relevant. > > This is primarily about clarifying which is correct as I would have > presumed that if something is right aligned and it exceeds it's parents > bounds, it will overflow in the direction it was assigned. > > Thanks, > > Robert Meyer >
Image align and overflow behaviour since complex scripts patch
Hi, I have noticed that since the complex scripts change, if you right-align an image in a cell and it exceeds the bounds of the cell, it will start expanding in the opposite direction as opposed to staying locked to the right side. Is this behaviour correct? I have attached two PDF's showing this with one run on trunk and one using code from before the patch. >From looking in the code there is now a check on line 352 in >LineLayoutManager.java which checks the difference for a negative value before >its assigned to the startIndent. If it is found to be the case, its changed to >0 which prevents the content from overrunning the left side. Although its a >bit cryptic, I found the following under the external-graphic section in the >XSL:FO specification which leads me to believe it should stay locked to the >direction assigned by the text-align property: "Once scaled, the reference-area is aligned with respect to the viewport-area using the text-align and display-align traits. If it is too large for the viewport-area, the graphic is aligned as if it would fit and the overflow trait controls the clipping, scroll bars, etc." I did also notice that negative start-indent values are allowed under blocks, but I am not sure if this is relevant. This is primarily about clarifying which is correct as I would have presumed that if something is right aligned and it exceeds it's parents bounds, it will overflow in the direction it was assigned. Thanks, Robert Meyer output-old.pdf Description: Adobe PDF document output-trunk.pdf Description: Adobe PDF document
Re: complex scripts patch committed
Nice work Glenn! "My religion is simple. My religion is kindness." - HH The Dalai Lama of Tibet On Feb 26, 2012, at 12:09 AM, Glenn Adams wrote: > it looks like this commit didn't break the nightly trunk build, as it just > completed without error [1] > > [1] http://ci.apache.org/builders/fop-trunk/ > > whew... > > On Sat, Feb 25, 2012 at 8:40 PM, Glenn Adams wrote: > The complex scripts (CS) patch is now committed to trunk at revision 1293736 > [1]. > > [1] http://svn.apache.org/viewvc?view=revision&revision=1293736 >
Re: complex scripts patch committed
it looks like this commit didn't break the nightly trunk build, as it just completed without error [1] [1] http://ci.apache.org/builders/fop-trunk/ whew... On Sat, Feb 25, 2012 at 8:40 PM, Glenn Adams wrote: > The complex scripts (CS) patch is now committed to trunk at revision > 1293736 [1]. > > [1] http://svn.apache.org/viewvc?view=revision&revision=1293736 >
complex scripts patch committed
The complex scripts (CS) patch is now committed to trunk at revision 1293736 [1]. [1] http://svn.apache.org/viewvc?view=revision&revision=1293736 The functionality added by this patch is enabled by default. If you do not need complex script support or do not need the benefit of OpenType Advanced Typographic Tables (e.g., advanced kerning, ligatures, etc) in non-complex scripts, then you can disable these features by one of three mechanisms: (1) add false to your fop.xconf file (as a child of the element), or (2) specify -nocs option as a command line option when invoking FOP, or (3) invoke setComplexScriptFeaturesEnabled(false) on the FOUserAgent instance you use programmatically; If you do not disable complex script features and you use non-complex scripts, there is a small processing and memory penalty which would not be incurred otherwise. Furthermore, for large fonts with many OpenType Advanced Typographic Tables, such as Arial Unicode MS, you may notice a significant processing penalty at font load time. At present, the complex script features support only PDF, AT (XML), and IF output formats. Support for other formats is expected to be added over time, depending on user needs. In particular, support for PS, PCL, AFP, RTF, Java2D, and image output formats is not yet implemented. Other limitations apply to CS features as well, including: - only OpenType advanced typographic tables supported - only certain complex scripts are supported in this initial patch, specifically Arabic, Hebrew, Devanagari, and preliminary (largely untested) support for Gujarati and Gurmukhi - only certain OpenType CS fonts have been tested, see [2] for the current list; [2] http://skynav.trac.cvsdude.com/fop/wiki/SupportedFonts I will be migrating (to the Apache FOP documentation and wiki) and enhancing the (limited) documentation I originally provided at [3]. So stay tuned for updates. [3] http://skynav.trac.cvsdude.com/fop/wiki/ComplexScripts Finally, to give you advance warning, you will notice when you run this new FOP the first time that your font cache will be rebuilt. This is because the serialized font cache data has changed, and thus the old version of the cache won't load. If you switch back and forth between this new work and the pre-CS trunk, then the older form of the font cache will be rebuilt. I have noticed that rebuilding the font cache often takes quite a bit of VM space, and, as a consequence, you might run out of memory if you run FOP the first time on a large FO file in combination with rebuilding the font cache. One way to deal with this is to first run FOP on a small, input file that has the side effect of rebuilding the font cache. Subsequent invocations will not have a problem since they won't rebuild the cache a second time. Regards, Glenn
Complex Scripts Patch
I have posted a new patch [1] against trunk (revision 1236835). [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=49687#c48 This patch is a cumulative patch, that, if applied to the specified trunk revision, brings up to date the trunk to my current FOP Complex Scripts repository state. The main changes in this patch include bug fixes, new features, and refactoring and cleanup, about which see [1] for additional details. Of particular relevance is that this patch attempts to address a number of comments previously made by reviewers, specifically: - need to reduce the size of large class files - this was accomplished by promoting nested classes to non-nested classes and by further subdividing functionality into distinct classes, e.g., the parsing of advanced typographic tables was moved from TTFFile into a new class OTFAdvancedTypographicTableReader; - need to reduce dependency of bidi functionality on specific FONode and Area class types - this was accomplished by better using the class hierarchy of FONode and Area classes (as opposed to excessive use of instanceof), see, e.g., FONode.collectDelimitedTextRanges(...) and InlineArea.collectInlineRuns(...); - need to better segregate complex script functionality - with the exception of FONode and Area specific semantics, this was accomplished by moving most new complex script functionality into a new package hierarchy org.apache.fop.complexscripts I believe this patch is ready to be merged into trunk. I am willing to help facilitate this process however I can. Regards, Glenn
