Created attachment 27712 [details] FO File for reproducing problem I used complex script from the following location: http://people.apache.org/~spepping/ I ran the command to generate an FO as follows: c:\fop-ComplexScripts\fop.cmd -c c:\fop-ComplexScripts\conf\fop.xconf -fo Arabic.fo -pdf Arabic.pdf I attach the fo file and the fop.xconf file. The FOP code seems to go into an infinite loop. Here is the output before FOP seemingly hangs forever. C:\InterSystems\cache121\MGR\Temp>c:\fop-ComplexScripts\fop.cmd -c c:\fop-Comple xScripts\conf\fop.xconf -fo Arabic.fo -pdf Arabic.pdf Oct 6, 2011 6:49:16 PM org.apache.fop.apps.FopFactoryConfigurator configure INFO: Default page-height set to: 11in Oct 6, 2011 6:49:16 PM org.apache.fop.apps.FopFactoryConfigurator configure INFO: Default page-width set to: 8.26in Oct 6, 2011 6:49:18 PM org.apache.fop.layoutmgr.table.ColumnSetup computeTableUn it WARNING: No space remaining to distribute over columns.
Created attachment 27713 [details] fop.xconf used in reproducing problem This is the fop.xconf I used in what looks like an infinite loop problem.
The supplied input FO file WORKSFORME without any loop behavior, execution time 3 secs (mostly startup). I'm attaching the output PDF file. I did not use the XCONF file. For the most part, you do not need to use XCONF to configure fonts in FOP 1.0 and later, unless you wish to subset your system installed fonts. My XCONF file has the following PDF renderer configuration: <renderer mime="application/pdf"> <filterList> <value>flate</value> </filterList> <fonts> <auto-detect/> </fonts> </renderer> I'm using my current dev work branch at [1]. I can't say whether the build you tried works or not, as that is not one of my builds. Also, please note the following: (1) in general, you should use fonts designed for Arabic and indicated to be supported at [2], e.g., Simplified Arabic, Traditional Arabic, etc.; other OpenType fonts that contain Arabic glyphs and OpenType AAT (GSUB/GPOS) tables may work, but haven't been verified; [apparently Arial on my Mac does happen to have Arabic glyphs and OTF AAT tables, so it happens to work] (2) you should use the writing-mode attribute on fo:page-sequence (or on fo:block-container) to specify the writing mode of the generated reference areas; for example, specifying writing-mode="rl" on fo:page-sequence will automatically make the first column in a multi-column page the right-most column, and make the first column in a table the right-most column, and will align the start edge with the right edge, so you don't need to explicitly specify right alignment; note that text-align="start|end" is now resolved according to writing mode; [1] http://github.com/skynavga/fop [2] http://skynav.trac.cvsdude.com/fop/wiki/SupportedFonts
Created attachment 27743 [details] generated PDF using arial with current dev branch code
This could be related to: https://issues.apache.org/bugzilla/show_bug.cgi?id=51282 which was actually a bug introduced in trunk. Probably you are using an older version of the complex script branch, where the fix hasn't been merged yet.
(In reply to comment #2) > (2) you should use the writing-mode attribute on fo:page-sequence (or on > fo:block-container) to specify the writing mode of the generated reference > areas; for example, specifying writing-mode="rl" on fo:page-sequence will > automatically make the first column in a multi-column page the right-most > column, and make the first column in a table the right-most column, and will > align the start edge with the right edge, so you don't need to explicitly > specify right alignment; note that text-align="start|end" is now resolved > according to writing mode; I should also add that an important effect of using writing-mode="rl" on fo:page-sequence is that this makes the default bidirectional level right-to-left on blocks (e.g., paragraphs). If you then need to have certain blocks use left-to-right as their default bidi level, then you can use one of the following: (1) wrap the block's content with fo:bidi-override, e.g., <fo:block><fo:bidi-override unicode-bidi="embed" direction="ltr">...</fo:bidi-override></block> (2) wrap the block's content with explicit Unicode bidi control characters (i.e., RLE and PDF): <fo:block>‪...‬</block> (3) wrap the block with a relative block-container with a left-to-right writing mode, e.g., <fo:block-container writing-mode="lr"><fo:block>...</fo:block></fo:block-container> These techniques actually produce slightly different treatment at the bidi level. The first and second above keep the block at the same default bidi level prescribed by the page-sequence's writing mode, namely right-to-left, but inserts a new left-to-right embedding level into which the block's content is scoped. In contrast, the third technique actually changes the default bidi level of the blocks contained in the block-container to left-to-right.
batch transition to closed for remaining resolved bugs