Object reuse, and speeds

2012-11-08 Thread Dave Thorn
Hi,

I've seen in the documentation about reusing objects:

 Fop instances shouldn't (and can't) be reused. Please recreate
 Fop and FOUserAgent instances for each rendering run using the
 FopFactory. This is a cheap operation as all reusable information
 is held in the FopFactory. That's why it's so important to reuse
 the FopFactory instance.

But it seems that creating a newFop is a more expensive operation
than I was expecting:

FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent, out);

The 'newFop' call takes 600-700ms on my (not underpowered)
desktop.  I first started timing this after I'd made fonts
work, so I've noticed that if I remove the font config from my
fop config file[1], or just empty my fonts directory, then newFop
takes 100-150ms.

I have only 8 font files in my fonts directory (arial and arial
narrow, bold/italic/underline versions).  The font cache is being
created, so I presume it is also being used.

Is there any way to improve this speed?  A lot of the
documentation on the web seems to relate to earlier versions and
I've seen it mentioned that the way I'm doing it is correct for
1.0 (I intend to move to 1.1 once it's in the central maven
repositories).

A 500ms delay might not seem like a lot, but I'm trying to
replace an existing application, so I have a metric the newapp
will be judged by, and 500ms before we even begin the transform
(currently ~1500ms on an incomplete document) seems to be
starting on the back foot.


Thanks,


[1] renderers
renderer mime=application/pdf
  fonts

directory recursive=true/home/davet/fop/1/fonts/directory

  /fonts
/renderer
  /renderers

-- 
dave thorn

DBT; GBP.

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: post 1.1 config changes

2012-11-08 Thread Mehdi Houshmand
Hi Jason,

The backwards incompatibility of this API has been discussed quite a lot,
and I'm sorry you're having these issues. If you're looking for examples
for how to configure the new FopFactory, I'd say look in the source [1],
there are plenty of examples on how to do it, there's also quite a bit of
information on the wiki [2].

Sorry for the inconvenience,

Mehdi

[1]
http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/
[2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration


On 8 November 2012 01:54, Jason Harrop jhar...@gmail.com wrote:

 I maintain the docx4j project

 I reported https://issues.apache.org/bugzilla/show_bug.cgi?id=54094 which
 was apparently fixed in July, but didn't make it into FOP 1.1 (just
 released).

 So, I thought I'd test a FOP nightly (20121107) to verify it has been
 fixed.

 But config seems to have changed extensively post 1.1

 Post 1.1, I can see FopFactoryBuilder, mentioned at
 http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration which
 contains

 public FopFactoryBuilder setConfiguration(Configuration cfg) {
 fopFactoryConfigBuilder.setConfiguration(cfg);
 return this;
 }

 but that class didn't make it into 1.1 (it has FopFactoryConfigurator)

 So, Is it feasible/sensible to try to be interchangeable between FOP 1.1
 and whatever is to come?  Has someone written code which facilitates this?

 Please excuse if there are posts on this topic already.

 thanks .. Jason





Re: post 1.1 config changes

2012-11-08 Thread Jason Harrop
Hi Mehdi

Thanks for your reply.  I'm happy I can write configuration code for
current SVN head.  But my question is whether anyone has produced/shared
configuration code which works with both current SVN head, and FOP 1.1 ie
using reflection as necessary.

If not, we may just wait for the next release of FOP, and support only that.

thanks .. Jason


On Thu, Nov 8, 2012 at 8:44 PM, Mehdi Houshmand med1...@gmail.com wrote:

 Hi Jason,

 The backwards incompatibility of this API has been discussed quite a lot,
 and I'm sorry you're having these issues. If you're looking for examples
 for how to configure the new FopFactory, I'd say look in the source [1],
 there are plenty of examples on how to do it, there's also quite a bit of
 information on the wiki [2].

 Sorry for the inconvenience,

 Mehdi

 [1]
 http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/
 [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration


 On 8 November 2012 01:54, Jason Harrop jhar...@gmail.com wrote:

 I maintain the docx4j project

 I reported https://issues.apache.org/bugzilla/show_bug.cgi?id=54094 which
 was apparently fixed in July, but didn't make it into FOP 1.1 (just
 released).

 So, I thought I'd test a FOP nightly (20121107) to verify it has been
 fixed.

 But config seems to have changed extensively post 1.1

 Post 1.1, I can see FopFactoryBuilder, mentioned at
 http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration which
 contains

 public FopFactoryBuilder setConfiguration(Configuration cfg) {
 fopFactoryConfigBuilder.setConfiguration(cfg);
 return this;
 }

 but that class didn't make it into 1.1 (it has FopFactoryConfigurator)

 So, Is it feasible/sensible to try to be interchangeable between FOP 1.1
 and whatever is to come?  Has someone written code which facilitates this?

 Please excuse if there are posts on this topic already.

 thanks .. Jason






Re: post 1.1 config changes

2012-11-08 Thread Mehdi Houshmand
Hi Jason,

I don't think anyone has, or if they have, they haven't published it to the
community.

Hope that helps,

Mehdi


On 8 November 2012 09:53, Jason Harrop jhar...@gmail.com wrote:

 Hi Mehdi

 Thanks for your reply.  I'm happy I can write configuration code for
 current SVN head.  But my question is whether anyone has produced/shared
 configuration code which works with both current SVN head, and FOP 1.1 ie
 using reflection as necessary.

 If not, we may just wait for the next release of FOP, and support only
 that.

 thanks .. Jason



 On Thu, Nov 8, 2012 at 8:44 PM, Mehdi Houshmand med1...@gmail.com wrote:

 Hi Jason,

 The backwards incompatibility of this API has been discussed quite a lot,
 and I'm sorry you're having these issues. If you're looking for examples
 for how to configure the new FopFactory, I'd say look in the source [1],
 there are plenty of examples on how to do it, there's also quite a bit of
 information on the wiki [2].

 Sorry for the inconvenience,

 Mehdi

 [1]
 http://svn.eu.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/
 [2] http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration


 On 8 November 2012 01:54, Jason Harrop jhar...@gmail.com wrote:

 I maintain the docx4j project

 I reported https://issues.apache.org/bugzilla/show_bug.cgi?id=54094 which
 was apparently fixed in July, but didn't make it into FOP 1.1 (just
 released).

 So, I thought I'd test a FOP nightly (20121107) to verify it has been
 fixed.

 But config seems to have changed extensively post 1.1

 Post 1.1, I can see FopFactoryBuilder, mentioned at
 http://wiki.apache.org/xmlgraphics-fop/FopFactoryConfiguration which
 contains

 public FopFactoryBuilder setConfiguration(Configuration cfg) {
 fopFactoryConfigBuilder.setConfiguration(cfg);
 return this;
 }

 but that class didn't make it into 1.1 (it has FopFactoryConfigurator)

 So, Is it feasible/sensible to try to be interchangeable between FOP 1.1
 and whatever is to come?  Has someone written code which facilitates this?

 Please excuse if there are posts on this topic already.

 thanks .. Jason







Re: Object reuse, and speeds

2012-11-08 Thread Dave Thorn
On Thu, Nov 08, 2012 at 09:37:57AM +, Mehdi Houshmand wrote:
 
[snip]
 try trunk and let me know if that helps; what you should find is that
 the first creation of the Fop object is as costly as it was before, but
 subsequent instantiations of the object shouldn't have as much of a
 performance impact.
 
 Let me know if that does what you're looking for,

Actually, that helps without me having to checkout the trunk.

If I actually simulate more closely proper application behaviour
(i.e. create one fopFactory and create-and-use multiple Fop
objects) then for the subsequent Fop object creations the time
drops to ~40-60ms.

I should really have tried that first.  But thank you.

I will try to put off using 1.1 until it's in the central maven
repository.

-- 
dave thorn

Hi, I'm from the Internet.

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: Need help to get Arabic working with FOP

2012-11-08 Thread Bernardo Gonzalez Kriegel
Hello,
I think that it's not so simple, but as Eduard pointed out you need:
a) a correct font
b) fop-1.1
c) fo generation
d) fop configuration

I am also frustrated, I have not been able to generate a PDF in Arabic.
So, these are my questions/experiences:

a) I'm using Arial Unicode MS [1]. It's a good choice?
b) I downloaded the last version from [2]
c) I tried xsltproc, that converts any gliph into character codes
(ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)),
or saxon that leaves the gliphs intact
(3.8 (بالعربية))
d) I've edited fop.xconf to register the font

In any case, not only fop refuses to generate a pdf, complaining about
missing glyphs and hyphenation,
but aborts with many org.apache.fop.fo.ValidationException.

So, anyone know's or can point to a document to learn about these questions
 a) What font is recommended, or have been used with success?
 b) What is the best way to generate the FO?
 c) What configuration do you use to register the font?
 d) There are any examples?

Best regards,
Bernardo

[1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24
[2] http://xmlgraphics.apache.org/fop/1.1/

-- 
Bernardo Gonzalez Kriegel
bgkrie...@gmail.com



On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote:

 Brian,

 It's simple. I'll try to explain.

 1. Check if fonts, available on your system, support Arabic glyphs.
 2. Write down (i.e. in any text editor) the names of these fonts.
 3. Open your fo file and check the names of the fonts you are using.
 Please, note, that the font families in your fo file should have the same
 names as your font files in your system.
 4. Try to use the exact fonts with Arabic glyphs instead of autodetect.
 Try to use the following:
 http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the
 step 2 in your mind).

 Finally, you need to get:
 1. The names of the fonts file in your system, that contains Arabic glyphs.
 2. The fo file with font families that exists in your system and contains
 Arabic glyphs.
 3. The configuration file that makes a dependency between the font files
 in your system and font names fo file.

 --
 Best regards,
  Eduard Tibet


 -Original Message-
 From: Brian Hansen [mailto:greencopperm...@gmail.com]
 Sent: Thursday, November 08, 2012 11:06 AM
 To: fop-users@xmlgraphics.apache.org
 Subject: Need help to get Arabic working with FOP

 Hi

 I'm pulling my hair out in frustration! I have been trying for so long
 to get Arabic fonts to display correct when using Docbook (converting
 XML to FO using Xsltproc and then to PDF using FOP).

 I'm sorry, but I just don't understand the documentation for FOP. It's
 not clear enough for me.

 I'm running FOP 1.0 on Linux. I need to know exacty, step by step,
 what I need to do to get Arabic text rendered properly. Instead # is
 shown.

 I have created this file foprc.xconf:

 fop
 renderers
 renderer mime=application/pdf
 fonts
 auto-detect/
 /fonts
 /renderer
 /renderers
 /fop

 When I run FOP I use this command:

 $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf

 I get this message:

 SNIP
 Font Symbol,normal,700 not found. Substituting with Symbol,normal,400.
 Font ZapfDingbats,normal,700 not found. Substituting with
 ZapfDingbats,normal,400.
 Glyph ? (0x627, afii57415) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Helvetica-Bold.
 Glyph ? (0x625, afii57413) not available in font Helvetica-Bold.
 Glyph ? (0x633, afii57427) not available in font Helvetica-Bold.
 Glyph ? (0x645, afii57445) not available in font Helvetica-Bold.
 Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold.
 Glyph ? (0x629, afii57417) not available in font Helvetica-Bold.
 Glyph ? (0x646, afii57446) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Times-Roman.
 Glyph ? (0x627, afii57415) not available in font Times-Roman.
 Glyph ? (0x625, afii57413) not available in font Times-Roman.
 Glyph ? (0x647, afii57470) not available in font Times-Roman.
 Glyph ? (0x62a, afii57418) not available in font Times-Roman.
 Glyph ? (0x642, afii57442) not available in font Times-Roman.
 Glyph ? (0x648, afii57448) not available in font Times-Roman.
 Glyph ? (0x649, afii57449) not available in font Times-Roman.
 Glyph ? (0x62e, afii57422) not available in font Times-Bold.
 Glyph ? (0x627, afii57415) not available in font Times-Bold.
 Glyph ? (0x641, afii57441) not available in font Times-Bold.
 Glyph ? (0x625, afii57413) not available in font Times-Bold.
 Glyph ? (0x650, afii57456) not available in font Times-Bold.
 Glyph ? (0x646, afii57446) not available in font Times-Bold.
 Glyph ? (0x651, afii57457) not available in font Times-Bold.
 Glyph ? (0x64e, afii57454) not available in font Times-Bold.
 Line 1 of a paragraph overflows the available area by 33725
 

Re: Need help to get Arabic working with FOP

2012-11-08 Thread Mehdi Houshmand
Hi Bernardo,

By the looks of the exception you've got an error in the FO you're
creating, which probably has nothing to do with Arabic support. If you're
wondering which fonts to use, I'd suggest you read the Apache FOP website,
it should give you all the information you need [1].

As for your erroneous FO, I'd suggest the following; use an XSLT
transformer to create the FO, then use that as the input to FOP and you
should get some information from the error as to which FO construct is
erroring. If you're still having issues, post the FO to this forum (though
under a new thread, it's won't be relevant to the original thread).

Hope that helps

Mehdi

[1] http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic


On 8 November 2012 11:39, Bernardo Gonzalez Kriegel bgkrie...@gmail.comwrote:

 Hello,
 I think that it's not so simple, but as Eduard pointed out you need:
 a) a correct font
 b) fop-1.1
 c) fo generation
 d) fop configuration

 I am also frustrated, I have not been able to generate a PDF in Arabic.
 So, these are my questions/experiences:

 a) I'm using Arial Unicode MS [1]. It's a good choice?
 b) I downloaded the last version from [2]
 c) I tried xsltproc, that converts any gliph into character codes
 (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)),
 or saxon that leaves the gliphs intact
 (3.8 (بالعربية))
 d) I've edited fop.xconf to register the font

 In any case, not only fop refuses to generate a pdf, complaining about
 missing glyphs and hyphenation,
 but aborts with many org.apache.fop.fo.ValidationException.

 So, anyone know's or can point to a document to learn about these questions
  a) What font is recommended, or have been used with success?
  b) What is the best way to generate the FO?
  c) What configuration do you use to register the font?
  d) There are any examples?

 Best regards,
 Bernardo

 [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24
 [2] http://xmlgraphics.apache.org/fop/1.1/

 --
 Bernardo Gonzalez Kriegel
 bgkrie...@gmail.com



 On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote:

 Brian,

 It's simple. I'll try to explain.

 1. Check if fonts, available on your system, support Arabic glyphs.
 2. Write down (i.e. in any text editor) the names of these fonts.
 3. Open your fo file and check the names of the fonts you are using.
 Please, note, that the font families in your fo file should have the same
 names as your font files in your system.
 4. Try to use the exact fonts with Arabic glyphs instead of autodetect.
 Try to use the following:
 http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the
 step 2 in your mind).

 Finally, you need to get:
 1. The names of the fonts file in your system, that contains Arabic
 glyphs.
 2. The fo file with font families that exists in your system and contains
 Arabic glyphs.
 3. The configuration file that makes a dependency between the font files
 in your system and font names fo file.

 --
 Best regards,
  Eduard Tibet


 -Original Message-
 From: Brian Hansen [mailto:greencopperm...@gmail.com]
 Sent: Thursday, November 08, 2012 11:06 AM
 To: fop-users@xmlgraphics.apache.org
 Subject: Need help to get Arabic working with FOP

 Hi

 I'm pulling my hair out in frustration! I have been trying for so long
 to get Arabic fonts to display correct when using Docbook (converting
 XML to FO using Xsltproc and then to PDF using FOP).

 I'm sorry, but I just don't understand the documentation for FOP. It's
 not clear enough for me.

 I'm running FOP 1.0 on Linux. I need to know exacty, step by step,
 what I need to do to get Arabic text rendered properly. Instead # is
 shown.

 I have created this file foprc.xconf:

 fop
 renderers
 renderer mime=application/pdf
 fonts
 auto-detect/
 /fonts
 /renderer
 /renderers
 /fop

 When I run FOP I use this command:

 $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf

 I get this message:

 SNIP
 Font Symbol,normal,700 not found. Substituting with Symbol,normal,400.
 Font ZapfDingbats,normal,700 not found. Substituting with
 ZapfDingbats,normal,400.
 Glyph ? (0x627, afii57415) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Helvetica-Bold.
 Glyph ? (0x625, afii57413) not available in font Helvetica-Bold.
 Glyph ? (0x633, afii57427) not available in font Helvetica-Bold.
 Glyph ? (0x645, afii57445) not available in font Helvetica-Bold.
 Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold.
 Glyph ? (0x629, afii57417) not available in font Helvetica-Bold.
 Glyph ? (0x646, afii57446) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Times-Roman.
 Glyph ? (0x627, afii57415) not available in font Times-Roman.
 Glyph ? (0x625, afii57413) not available in font Times-Roman.
 Glyph ? (0x647, 

Re: Need help to get Arabic working with FOP

2012-11-08 Thread Luis Bernardo
an example is attached. in fact it was provided in this list by
someone else by I am including also a fop.xconf file.

On Thu, Nov 8, 2012 at 11:39 AM, Bernardo Gonzalez Kriegel
bgkrie...@gmail.com wrote:
 Hello,
 I think that it's not so simple, but as Eduard pointed out you need:
 a) a correct font
 b) fop-1.1
 c) fo generation
 d) fop configuration

 I am also frustrated, I have not been able to generate a PDF in Arabic.
 So, these are my questions/experiences:

 a) I'm using Arial Unicode MS [1]. It's a good choice?
 b) I downloaded the last version from [2]
 c) I tried xsltproc, that converts any gliph into character codes
 (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)),
 or saxon that leaves the gliphs intact
 (3.8 (بالعربية))
 d) I've edited fop.xconf to register the font

 In any case, not only fop refuses to generate a pdf, complaining about
 missing glyphs and hyphenation,
 but aborts with many org.apache.fop.fo.ValidationException.

 So, anyone know's or can point to a document to learn about these questions
  a) What font is recommended, or have been used with success?
  b) What is the best way to generate the FO?
  c) What configuration do you use to register the font?
  d) There are any examples?

 Best regards,
 Bernardo

 [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24
 [2] http://xmlgraphics.apache.org/fop/1.1/

 --
 Bernardo Gonzalez Kriegel
 bgkrie...@gmail.com



 On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.com
 wrote:

 Brian,

 It's simple. I'll try to explain.

 1. Check if fonts, available on your system, support Arabic glyphs.
 2. Write down (i.e. in any text editor) the names of these fonts.
 3. Open your fo file and check the names of the fonts you are using.
 Please, note, that the font families in your fo file should have the same
 names as your font files in your system.
 4. Try to use the exact fonts with Arabic glyphs instead of autodetect.
 Try to use the following:
 http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the step
 2 in your mind).

 Finally, you need to get:
 1. The names of the fonts file in your system, that contains Arabic
 glyphs.
 2. The fo file with font families that exists in your system and contains
 Arabic glyphs.
 3. The configuration file that makes a dependency between the font files
 in your system and font names fo file.

 --
 Best regards,
  Eduard Tibet


 -Original Message-
 From: Brian Hansen [mailto:greencopperm...@gmail.com]
 Sent: Thursday, November 08, 2012 11:06 AM
 To: fop-users@xmlgraphics.apache.org
 Subject: Need help to get Arabic working with FOP

 Hi

 I'm pulling my hair out in frustration! I have been trying for so long
 to get Arabic fonts to display correct when using Docbook (converting
 XML to FO using Xsltproc and then to PDF using FOP).

 I'm sorry, but I just don't understand the documentation for FOP. It's
 not clear enough for me.

 I'm running FOP 1.0 on Linux. I need to know exacty, step by step,
 what I need to do to get Arabic text rendered properly. Instead # is
 shown.

 I have created this file foprc.xconf:

 fop
 renderers
 renderer mime=application/pdf
 fonts
 auto-detect/
 /fonts
 /renderer
 /renderers
 /fop

 When I run FOP I use this command:

 $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf

 I get this message:

 SNIP
 Font Symbol,normal,700 not found. Substituting with Symbol,normal,400.
 Font ZapfDingbats,normal,700 not found. Substituting with
 ZapfDingbats,normal,400.
 Glyph ? (0x627, afii57415) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Helvetica-Bold.
 Glyph ? (0x625, afii57413) not available in font Helvetica-Bold.
 Glyph ? (0x633, afii57427) not available in font Helvetica-Bold.
 Glyph ? (0x645, afii57445) not available in font Helvetica-Bold.
 Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold.
 Glyph ? (0x629, afii57417) not available in font Helvetica-Bold.
 Glyph ? (0x646, afii57446) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Times-Roman.
 Glyph ? (0x627, afii57415) not available in font Times-Roman.
 Glyph ? (0x625, afii57413) not available in font Times-Roman.
 Glyph ? (0x647, afii57470) not available in font Times-Roman.
 Glyph ? (0x62a, afii57418) not available in font Times-Roman.
 Glyph ? (0x642, afii57442) not available in font Times-Roman.
 Glyph ? (0x648, afii57448) not available in font Times-Roman.
 Glyph ? (0x649, afii57449) not available in font Times-Roman.
 Glyph ? (0x62e, afii57422) not available in font Times-Bold.
 Glyph ? (0x627, afii57415) not available in font Times-Bold.
 Glyph ? (0x641, afii57441) not available in font Times-Bold.
 Glyph ? (0x625, afii57413) not available in font Times-Bold.
 Glyph ? (0x650, afii57456) not available in font Times-Bold.
 Glyph ? 

Re: Need help to get Arabic working with FOP

2012-11-08 Thread Bernardo Gonzalez Kriegel
Luis,
I could re-generate the example, so I think my problem is in the fo
generation side.

Many thanks,
Bernardo
-- 
Bernardo Gonzalez Kriegel
bgkrie...@gmail.com



On Thu, Nov 8, 2012 at 9:26 AM, Luis Bernardo lmpmberna...@gmail.comwrote:

 an example is attached. in fact it was provided in this list by
 someone else by I am including also a fop.xconf file.

 On Thu, Nov 8, 2012 at 11:39 AM, Bernardo Gonzalez Kriegel
 bgkrie...@gmail.com wrote:
  Hello,
  I think that it's not so simple, but as Eduard pointed out you need:
  a) a correct font
  b) fop-1.1
  c) fo generation
  d) fop configuration
 
  I am also frustrated, I have not been able to generate a PDF in Arabic.
  So, these are my questions/experiences:
 
  a) I'm using Arial Unicode MS [1]. It's a good choice?
  b) I downloaded the last version from [2]
  c) I tried xsltproc, that converts any gliph into character codes
  (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)),
  or saxon that leaves the gliphs intact
  (3.8 (بالعربية))
  d) I've edited fop.xconf to register the font
 
  In any case, not only fop refuses to generate a pdf, complaining about
  missing glyphs and hyphenation,
  but aborts with many org.apache.fop.fo.ValidationException.
 
  So, anyone know's or can point to a document to learn about these
 questions
   a) What font is recommended, or have been used with success?
   b) What is the best way to generate the FO?
   c) What configuration do you use to register the font?
   d) There are any examples?
 
  Best regards,
  Bernardo
 
  [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24
  [2] http://xmlgraphics.apache.org/fop/1.1/
 
  --
  Bernardo Gonzalez Kriegel
  bgkrie...@gmail.com
 
 
 
  On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.com
  wrote:
 
  Brian,
 
  It's simple. I'll try to explain.
 
  1. Check if fonts, available on your system, support Arabic glyphs.
  2. Write down (i.e. in any text editor) the names of these fonts.
  3. Open your fo file and check the names of the fonts you are using.
  Please, note, that the font families in your fo file should have the
 same
  names as your font files in your system.
  4. Try to use the exact fonts with Arabic glyphs instead of autodetect.
  Try to use the following:
  http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold
 the step
  2 in your mind).
 
  Finally, you need to get:
  1. The names of the fonts file in your system, that contains Arabic
  glyphs.
  2. The fo file with font families that exists in your system and
 contains
  Arabic glyphs.
  3. The configuration file that makes a dependency between the font files
  in your system and font names fo file.
 
  --
  Best regards,
   Eduard Tibet
 
 
  -Original Message-
  From: Brian Hansen [mailto:greencopperm...@gmail.com]
  Sent: Thursday, November 08, 2012 11:06 AM
  To: fop-users@xmlgraphics.apache.org
  Subject: Need help to get Arabic working with FOP
 
  Hi
 
  I'm pulling my hair out in frustration! I have been trying for so long
  to get Arabic fonts to display correct when using Docbook (converting
  XML to FO using Xsltproc and then to PDF using FOP).
 
  I'm sorry, but I just don't understand the documentation for FOP. It's
  not clear enough for me.
 
  I'm running FOP 1.0 on Linux. I need to know exacty, step by step,
  what I need to do to get Arabic text rendered properly. Instead # is
  shown.
 
  I have created this file foprc.xconf:
 
  fop
  renderers
  renderer mime=application/pdf
  fonts
  auto-detect/
  /fonts
  /renderer
  /renderers
  /fop
 
  When I run FOP I use this command:
 
  $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf
 
  I get this message:
 
  SNIP
  Font Symbol,normal,700 not found. Substituting with
 Symbol,normal,400.
  Font ZapfDingbats,normal,700 not found. Substituting with
  ZapfDingbats,normal,400.
  Glyph ? (0x627, afii57415) not available in font Helvetica-Bold.
  Glyph ? (0x644, afii57444) not available in font Helvetica-Bold.
  Glyph ? (0x625, afii57413) not available in font Helvetica-Bold.
  Glyph ? (0x633, afii57427) not available in font Helvetica-Bold.
  Glyph ? (0x645, afii57445) not available in font Helvetica-Bold.
  Glyph ? (0x64a, afii57450) not available in font Helvetica-Bold.
  Glyph ? (0x629, afii57417) not available in font Helvetica-Bold.
  Glyph ? (0x646, afii57446) not available in font Helvetica-Bold.
  Glyph ? (0x644, afii57444) not available in font Times-Roman.
  Glyph ? (0x627, afii57415) not available in font Times-Roman.
  Glyph ? (0x625, afii57413) not available in font Times-Roman.
  Glyph ? (0x647, afii57470) not available in font Times-Roman.
  Glyph ? (0x62a, afii57418) not available in font Times-Roman.
  Glyph ? (0x642, afii57442) not available in font Times-Roman.
  Glyph ? (0x648, afii57448) not available in font Times-Roman.
  

Re: Need help to get Arabic working with FOP

2012-11-08 Thread Bernardo Gonzalez Kriegel
Hi Mehdi,

You are right, I used the example and configuration sent by Luis Bernardo,
and fop works well.
As for the fonts, his (Luis) example used Arial, I also tested
ArialUnicodeMS and works.
Traditional arabic (BTW, the links on the page are wrong) produces this
error:

org.apache.fop.apps.FOPException: The font trado.ttf is not embeddable due
to a licensing restriction.

Thank you,
Bernardo

-- 
Bernardo Gonzalez Kriegel
bgkrie...@gmail.com



On Thu, Nov 8, 2012 at 9:12 AM, Mehdi Houshmand med1...@gmail.com wrote:

 Hi Bernardo,

 By the looks of the exception you've got an error in the FO you're
 creating, which probably has nothing to do with Arabic support. If you're
 wondering which fonts to use, I'd suggest you read the Apache FOP website,
 it should give you all the information you need [1].

 As for your erroneous FO, I'd suggest the following; use an XSLT
 transformer to create the FO, then use that as the input to FOP and you
 should get some information from the error as to which FO construct is
 erroring. If you're still having issues, post the FO to this forum (though
 under a new thread, it's won't be relevant to the original thread).

 Hope that helps

 Mehdi

 [1]
 http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic


 On 8 November 2012 11:39, Bernardo Gonzalez Kriegel 
 bgkrie...@gmail.comwrote:

 Hello,
 I think that it's not so simple, but as Eduard pointed out you need:
 a) a correct font
 b) fop-1.1
 c) fo generation
 d) fop configuration

 I am also frustrated, I have not been able to generate a PDF in Arabic.
 So, these are my questions/experiences:

 a) I'm using Arial Unicode MS [1]. It's a good choice?
 b) I downloaded the last version from [2]
 c) I tried xsltproc, that converts any gliph into character codes
 (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)),
 or saxon that leaves the gliphs intact
 (3.8 (بالعربية))
 d) I've edited fop.xconf to register the font

 In any case, not only fop refuses to generate a pdf, complaining about
 missing glyphs and hyphenation,
 but aborts with many org.apache.fop.fo.ValidationException.

 So, anyone know's or can point to a document to learn about these
 questions
  a) What font is recommended, or have been used with success?
  b) What is the best way to generate the FO?
  c) What configuration do you use to register the font?
  d) There are any examples?

 Best regards,
 Bernardo

 [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24
 [2] http://xmlgraphics.apache.org/fop/1.1/

 --
 Bernardo Gonzalez Kriegel
 bgkrie...@gmail.com



 On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote:

 Brian,

 It's simple. I'll try to explain.

 1. Check if fonts, available on your system, support Arabic glyphs.
 2. Write down (i.e. in any text editor) the names of these fonts.
 3. Open your fo file and check the names of the fonts you are using.
 Please, note, that the font families in your fo file should have the same
 names as your font files in your system.
 4. Try to use the exact fonts with Arabic glyphs instead of autodetect.
 Try to use the following:
 http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold the
 step 2 in your mind).

 Finally, you need to get:
 1. The names of the fonts file in your system, that contains Arabic
 glyphs.
 2. The fo file with font families that exists in your system and
 contains Arabic glyphs.
 3. The configuration file that makes a dependency between the font files
 in your system and font names fo file.

 --
 Best regards,
  Eduard Tibet


 -Original Message-
 From: Brian Hansen [mailto:greencopperm...@gmail.com]
 Sent: Thursday, November 08, 2012 11:06 AM
 To: fop-users@xmlgraphics.apache.org
 Subject: Need help to get Arabic working with FOP

 Hi

 I'm pulling my hair out in frustration! I have been trying for so long
 to get Arabic fonts to display correct when using Docbook (converting
 XML to FO using Xsltproc and then to PDF using FOP).

 I'm sorry, but I just don't understand the documentation for FOP. It's
 not clear enough for me.

 I'm running FOP 1.0 on Linux. I need to know exacty, step by step,
 what I need to do to get Arabic text rendered properly. Instead # is
 shown.

 I have created this file foprc.xconf:

 fop
 renderers
 renderer mime=application/pdf
 fonts
 auto-detect/
 /fonts
 /renderer
 /renderers
 /fop

 When I run FOP I use this command:

 $ fop -c foprc.xconf -fo filename.fo -pdf filename.pdf

 I get this message:

 SNIP
 Font Symbol,normal,700 not found. Substituting with
 Symbol,normal,400.
 Font ZapfDingbats,normal,700 not found. Substituting with
 ZapfDingbats,normal,400.
 Glyph ? (0x627, afii57415) not available in font Helvetica-Bold.
 Glyph ? (0x644, afii57444) not available in font Helvetica-Bold.
 Glyph ? (0x625, afii57413) not available in font 

Re: Need help to get Arabic working with FOP

2012-11-08 Thread Mehdi Houshmand
Ahh yeah, that doesn't mean it doesn't work though. You can reference fonts
[1], but you'll need them installed if you want to view them. Alternatively
you could either 1) buy the license or 2) uhm *cough* change the bit flag
which tells Fop the font is not embeddable [2] *cough*... Woahh that was an
informative cough!

Obviously any changes you make to the font are ill advised in a commercial
setting, but may help you test the font before purchasing it.

Mehdi

[1] http://xmlgraphics.apache.org/fop/1.1/fonts.html
*cough* [2] http://www.microsoft.com/typography/otspec/os2.htm#fst *cough*


On 8 November 2012 13:30, Bernardo Gonzalez Kriegel bgkrie...@gmail.comwrote:

 Hi Mehdi,

 You are right, I used the example and configuration sent by Luis Bernardo,
 and fop works well.
 As for the fonts, his (Luis) example used Arial, I also tested
 ArialUnicodeMS and works.
 Traditional arabic (BTW, the links on the page are wrong) produces this
 error:

 org.apache.fop.apps.FOPException: The font trado.ttf is not embeddable due
 to a licensing restriction.

 Thank you,
 Bernardo

 --
 Bernardo Gonzalez Kriegel
 bgkrie...@gmail.com



 On Thu, Nov 8, 2012 at 9:12 AM, Mehdi Houshmand med1...@gmail.com wrote:

 Hi Bernardo,

 By the looks of the exception you've got an error in the FO you're
 creating, which probably has nothing to do with Arabic support. If you're
 wondering which fonts to use, I'd suggest you read the Apache FOP website,
 it should give you all the information you need [1].

 As for your erroneous FO, I'd suggest the following; use an XSLT
 transformer to create the FO, then use that as the input to FOP and you
 should get some information from the error as to which FO construct is
 erroring. If you're still having issues, post the FO to this forum (though
 under a new thread, it's won't be relevant to the original thread).

 Hope that helps

 Mehdi

 [1]
 http://xmlgraphics.apache.org/fop/trunk/complexscripts.html#fonts_arabic


 On 8 November 2012 11:39, Bernardo Gonzalez Kriegel 
 bgkrie...@gmail.comwrote:

 Hello,
 I think that it's not so simple, but as Eduard pointed out you need:
 a) a correct font
 b) fop-1.1
 c) fo generation
 d) fop configuration

 I am also frustrated, I have not been able to generate a PDF in Arabic.
 So, these are my questions/experiences:

 a) I'm using Arial Unicode MS [1]. It's a good choice?
 b) I downloaded the last version from [2]
 c) I tried xsltproc, that converts any gliph into character codes
 (ej. 3.8 (#x628;#x627;#x644;#x639;#x631;#x628;#x64A;#x629;)),
 or saxon that leaves the gliphs intact
 (3.8 (بالعربية))
 d) I've edited fop.xconf to register the font

 In any case, not only fop refuses to generate a pdf, complaining about
 missing glyphs and hyphenation,
 but aborts with many org.apache.fop.fo.ValidationException.

 So, anyone know's or can point to a document to learn about these
 questions
  a) What font is recommended, or have been used with success?
  b) What is the best way to generate the FO?
  c) What configuration do you use to register the font?
  d) There are any examples?

 Best regards,
 Bernardo

 [1] http://www.microsoft.com/typography/fonts/family.aspx?fid=24
 [2] http://xmlgraphics.apache.org/fop/1.1/

 --
 Bernardo Gonzalez Kriegel
 bgkrie...@gmail.com



 On Thu, Nov 8, 2012 at 4:53 AM, Eduard Tibet eduard.ti...@i-free.comwrote:

 Brian,

 It's simple. I'll try to explain.

 1. Check if fonts, available on your system, support Arabic glyphs.
 2. Write down (i.e. in any text editor) the names of these fonts.
 3. Open your fo file and check the names of the fonts you are using.
 Please, note, that the font families in your fo file should have the same
 names as your font files in your system.
 4. Try to use the exact fonts with Arabic glyphs instead of autodetect.
 Try to use the following:
 http://xmlgraphics.apache.org/fop/1.1/fonts.html#advanced (but hold
 the step 2 in your mind).

 Finally, you need to get:
 1. The names of the fonts file in your system, that contains Arabic
 glyphs.
 2. The fo file with font families that exists in your system and
 contains Arabic glyphs.
 3. The configuration file that makes a dependency between the font
 files in your system and font names fo file.

 --
 Best regards,
  Eduard Tibet


 -Original Message-
 From: Brian Hansen [mailto:greencopperm...@gmail.com]
 Sent: Thursday, November 08, 2012 11:06 AM
 To: fop-users@xmlgraphics.apache.org
 Subject: Need help to get Arabic working with FOP

 Hi

 I'm pulling my hair out in frustration! I have been trying for so long
 to get Arabic fonts to display correct when using Docbook (converting
 XML to FO using Xsltproc and then to PDF using FOP).

 I'm sorry, but I just don't understand the documentation for FOP. It's
 not clear enough for me.

 I'm running FOP 1.0 on Linux. I need to know exacty, step by step,
 what I need to do to get Arabic text rendered properly. Instead # is
 shown.

 I have created this file foprc.xconf:

 fop
 

Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way). When the black background is under the sidebar (as made with 
the referenced sidebar.fo) the nuisance-some inter-cell lines expose the 
black underlay. (Our fix is to not put the black under the sidebar.)


In the original thread Jeremias Maerki wrote

   I suspect it's once
   more Adobe's anti-aliasing to be blamed. And this won't show up in
   print,
   BTW. To get rid of this on display, go to Acrobat's Preferences Dialog,
   select Page Display and enable Enhance Thin Lines (AR X) or disable
   Smooth line Art. You may have to disable Use 2D graphics
   acceleration,
   too. Nothing FOP can do at the moment. I've recently explained on this
   list what would need to be done to work around Adobe's problem.

Since there is a path whereon they do show up in print, I wonder if this 
suggested work-around should be revisited? It's not clear to me that 
this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes back 
when adding the element/attr just removed (no matter what else is removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


I have reviewed the sidebar.fo http://sidebar.fo and it really
cannot be substantially reduced.  It simply fills the outer edge
of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page.  The
inner column is just spacer and the outer column gets the section
name(s) and number, a rule and a page number.  The names are
supplied in a rotated svg (not included).






RE: Fop download binary not working

2012-11-08 Thread Campbell, Lance
I just found that one can download FOP from the Archive Download link 
referenced at the bottom of the below URL.  That appears to be the only working 
URL for downloads unrelated to svn.

http://xmlgraphics.apache.org/fop/download.html


Thanks,

Lance Campbell
Software Architect
Web Services at Public Affairs
217-333-0382
[University of Illinois at Urbana-Champaign logo]http://illinois.edu/


From: Campbell, Lance [mailto:la...@illinois.edu]
Sent: Thursday, November 08, 2012 2:41 PM
To: fop-users@xmlgraphics.apache.org
Subject: Fop download binary not working

I am trying to download fop binary from the below URL but none of the URLs 
listed seem to work:

http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop

Any suggestions?

Thanks,

Lance Campbell
Software Architect
Web Services at Public Affairs
217-333-0382
[University of Illinois at Urbana-Champaign logo]http://illinois.edu/


inline: image003.pnginline: image004.png

How to configure FOP with Tomcat 7

2012-11-08 Thread Campbell, Lance
How do you configure FOP with Tomcat 7?  I found the below instruction.  But 
unfortunately I was unable to locate any instructions in Tomcat 7 that 
referenced FOP.  Any pointers would be great.

I found this referenced at:

http://xmlgraphics.apache.org/fop/1.1/servlets.html#tomcat

Tomcat
Check Tomcat's documentation for detailed instructions about installing FOP and 
Cocoon. There are known bugs that must be addressed, particularly for Tomcat 
4.0.3.

If I am emailing the wrong list for these questions please let me know.

Thanks,

Lance Campbell
Software Architect
Web Services at Public Affairs
217-333-0382
[University of Illinois at Urbana-Champaign logo]http://illinois.edu/


inline: image002.png

Re: Fop download binary not working

2012-11-08 Thread Glenn Adams
Apache @infra has been notified of this problem.

On Thu, Nov 8, 2012 at 12:57 PM, Campbell, Lance la...@illinois.edu wrote:

  I just found that one can download FOP from the Archive Download link
 referenced at the bottom of the below URL.  That appears to be the only
 working URL for downloads unrelated to svn.

 ** **

 http://xmlgraphics.apache.org/fop/download.html

 ** **

 ** **

 Thanks,

 ** **

 Lance Campbell

 Software Architect

 Web Services at Public Affairs

 217-333-0382

 [image: University of Illinois at Urbana-Champaign logo]http://illinois.edu/
 

 ** **

 ** **

 *From:* Campbell, Lance [mailto:la...@illinois.edu]
 *Sent:* Thursday, November 08, 2012 2:41 PM
 *To:* fop-users@xmlgraphics.apache.org
 *Subject:* Fop download binary not working

 ** **

 I am trying to download fop binary from the below URL but none of the URLs
 listed seem to work:

 ** **

 http://www.apache.org/dyn/closer.cgi/xmlgraphics/fop

 ** **

 Any suggestions?

 ** **

 Thanks,

 ** **

 Lance Campbell

 Software Architect

 Web Services at Public Affairs

 217-333-0382

 [image: University of Illinois at Urbana-Champaign logo]http://illinois.edu/
 

 ** **

 ** **

image003.pngimage004.png

INFRA-5498: xmlgraphics distribution artifacts have disappeared from dist servers

2012-11-08 Thread Glenn Adams
https://issues.apache.org/jira/browse/INFRA-5498

On Tue, Nov 6, 2012 at 8:22 AM, pct...@apache.org wrote:

 Author: pctony
 Date: Tue Nov  6 16:22:32 2012
 New Revision: 957

 Log:
 Adding XML


 Added:
 release/xmlgraphics/




Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Luis Bernardo


Rob, I looked with more time at this issue and I think that my previous 
statement that I was seeing lines where they should not be was 
incorrect. I think they should be there because they are in the *fo source!


It is true that no lines appear with Adobe, but they are visible both 
with Mac's Preview and Linux's Evince. But the lines are only in the 
column that does not spans rows, the one with the blue background. I do 
not see them in the column that spans rows. More than that I do not see 
any unexpected drawing commands in the PDF source.


Can you please explain again what lines are you seeing in the printer 
output? Are they in the blue column or in the white column?


On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way).  When the black background is under the sidebar (as made 
with the referenced sidebar.fo) the nuisance-some inter-cell lines 
expose the black underlay. (Our fix is to not put the black under the 
sidebar.)


In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show up in
print,
BTW. To get rid of this on display, go to Acrobat's Preferences
Dialog,
select Page Display and enable Enhance Thin Lines (AR X) or
disable
Smooth line Art. You may have to disable Use 2D graphics
acceleration,
too. Nothing FOP can do at the moment. I've recently explained on
this
list what would need to be done to work around Adobe's problem.

Since there is a path whereon they do show up in print, I wonder if 
this suggested work-around should be revisited? It's not clear to me 
that this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes back 
when adding the element/attr just removed (no matter what else is 
removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


I have reviewed the sidebar.fo http://sidebar.fo and it really
cannot be substantially reduced.  It simply fills the outer
edge of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page. 
The inner column is just spacer and the outer column gets the

section name(s) and number, a rule and a page number.  The names
are supplied in a rotated svg (not included).








Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent
When I reviewed sidebar.fo, I completely neglected the colours and 
borders added for debug purposes (oh so long ago). Let me get you a 
clean version.  The spurious lines appear in the column which is not 
spanned by the inner cell in the first row.




On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my 
previous statement that I was seeing lines where they should not be 
was incorrect. I think they should be there because they are in the 
*fo source!


It is true that no lines appear with Adobe, but they are visible both 
with Mac's Preview and Linux's Evince. But the lines are only in the 
column that does not spans rows, the one with the blue background. I 
do not see them in the column that spans rows. More than that I do not 
see any unexpected drawing commands in the PDF source.


Can you please explain again what lines are you seeing in the printer 
output? Are they in the blue column or in the white column?


On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way).  When the black background is under the sidebar (as made 
with the referenced sidebar.fo) the nuisance-some inter-cell lines 
expose the black underlay. (Our fix is to not put the black under the 
sidebar.)


In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show up
in print,
BTW. To get rid of this on display, go to Acrobat's Preferences
Dialog,
select Page Display and enable Enhance Thin Lines (AR X) or
disable
Smooth line Art. You may have to disable Use 2D graphics
acceleration,
too. Nothing FOP can do at the moment. I've recently explained on
this
list what would need to be done to work around Adobe's problem.

Since there is a path whereon they do show up in print, I wonder if 
this suggested work-around should be revisited? It's not clear to me 
that this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes 
back when adding the element/attr just removed (no matter what else 
is removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


I have reviewed the sidebar.fo http://sidebar.fo and it really
cannot be substantially reduced.  It simply fills the outer
edge of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page. 
The inner column is just spacer and the outer column gets the

section name(s) and number, a rule and a page number.  The names
are supplied in a rotated svg (not included).










Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent
Please find attached a new fo which defines the sidebar for the left 
pages only.  The blue column will show the four lines separating each 
row, at least in Evince 3.4.0 (using poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my 
previous statement that I was seeing lines where they should not be 
was incorrect. I think they should be there because they are in the 
*fo source!


It is true that no lines appear with Adobe, but they are visible both 
with Mac's Preview and Linux's Evince. But the lines are only in the 
column that does not spans rows, the one with the blue background. I 
do not see them in the column that spans rows. More than that I do not 
see any unexpected drawing commands in the PDF source.


Can you please explain again what lines are you seeing in the printer 
output? Are they in the blue column or in the white column?


On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product.  Some 
pages get a black background from iText (certain graphics look better 
that way).  When the black background is under the sidebar (as made 
with the referenced sidebar.fo) the nuisance-some inter-cell lines 
expose the black underlay. (Our fix is to not put the black under the 
sidebar.)


In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show up
in print,
BTW. To get rid of this on display, go to Acrobat's Preferences
Dialog,
select Page Display and enable Enhance Thin Lines (AR X) or
disable
Smooth line Art. You may have to disable Use 2D graphics
acceleration,
too. Nothing FOP can do at the moment. I've recently explained on
this
list what would need to be done to work around Adobe's problem.

Since there is a path whereon they do show up in print, I wonder if 
this suggested work-around should be revisited? It's not clear to me 
that this is still out of FOP's hands?


Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:
remove elements/attrs until the problem goes away and only comes 
back when adding the element/attr just removed (no matter what else 
is removed)


On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


I have reviewed the sidebar.fo http://sidebar.fo and it really
cannot be substantially reduced.  It simply fills the outer
edge of our pages - region-start or region end - with a narrow
two-column, five-row table stretching the length of the page. 
The inner column is just spacer and the outer column gets the

section name(s) and number, a rule and a page number.  The names
are supplied in a rotated svg (not included).








?xml version=1.0 encoding=UTF-8?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; xmlns:xalan=http://xml.apache.org/xslt; xmlns:ec=xalan://com.amirsys.utilities.ElementConversion
  fo:layout-master-set
fo:page-sequence-master master-name=sidebars
  fo:repeatable-page-master-alternatives
fo:conditional-page-master-reference page-position=any odd-or-even=odd master-reference=sidebar-odd blank-or-not-blank=any /
fo:conditional-page-master-reference page-position=any odd-or-even=even master-reference=sidebar-even blank-or-not-blank=any /
  /fo:repeatable-page-master-alternatives
/fo:page-sequence-master
fo:simple-page-master page-width=8.5in page-height=11in master-name=sidebar-even
  fo:region-body margin-left=0.75in /
  fo:region-start region-name=side-bar-left extent=0.75in /
/fo:simple-page-master
fo:simple-page-master page-width=8.5in page-height=11in master-name=sidebar-odd
  fo:region-body margin-right=0.75in /
  fo:region-end region-name=side-bar-right extent=0.75in /
/fo:simple-page-master
  /fo:layout-master-set
  fo:page-sequence master-reference=sidebars initial-page-number=30
fo:static-content flow-name=side-bar-left
  fo:table width=0.75in table-layout=fixed border-collapse=collapse
fo:table-column column-width=0.5625in /
fo:table-column column-width=0.1875in /
fo:table-body
  fo:table-row height=9.6875in
fo:table-cell border-top-width=1pt background-color=#142850 border-right=0.5pt solid black
  fo:block
fo:external-graphic width=0.5in src=left.svg height=9in /
  /fo:block
/fo:table-cell
fo:table-cell number-rows-spanned=5 
  fo:block /
/fo:table-cell
  /fo:table-row
  fo:table-row
fo:table-cell  background-color=#142850 border-right=0.5pt solid black
  fo:block text-align=center font-size=5pt font-family=Optima /fo:block
/fo:table-cell
  /fo:table-row
  fo:table-row
fo:table-cell background-color=#142850 

Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Glenn Adams
what i said about maximally minimizing your test FO; when you don't do so,
you lead devs astray

On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com wrote:

  Please find attached a new fo which defines the sidebar for the left
 pages only.  The blue column will show the four lines separating each row,
 at least in Evince 3.4.0 (using poppler/cairo(0.18.4))


 On 11/08/2012 03:19 PM, Luis Bernardo wrote:


 Rob, I looked with more time at this issue and I think that my previous
 statement that I was seeing lines where they should not be was incorrect. I
 think they should be there because they are in the *fo source!

 It is true that no lines appear with Adobe, but they are visible both with
 Mac's Preview and Linux's Evince. But the lines are only in the column that
 does not spans rows, the one with the blue background. I do not see them in
 the column that spans rows. More than that I do not see any unexpected
 drawing commands in the PDF source.

 Can you please explain again what lines are you seeing in the printer
 output? Are they in the blue column or in the white column?

 On 11/8/12 5:40 PM, Rob Sargent wrote:

 We use iText as well as FOP in producing our printable product.  Some
 pages get a black background from iText (certain graphics look better that
 way).  When the black background is under the sidebar (as made with the
 referenced sidebar.fo) the nuisance-some inter-cell lines expose the
 black underlay. (Our fix is to not put the black under the sidebar.)

 In the original thread Jeremias Maerki wrote

 I suspect it's once
 more Adobe's anti-aliasing to be blamed. And this won't show up in print,
 BTW. To get rid of this on display, go to Acrobat's Preferences Dialog,
 select Page Display and enable Enhance Thin Lines (AR X) or disable
 Smooth line Art. You may have to disable Use 2D graphics acceleration,
 too. Nothing FOP can do at the moment. I've recently explained on this
 list what would need to be done to work around Adobe's problem.

 Since there is a path whereon they do show up in print, I wonder if this
 suggested work-around should be revisited? It's not clear to me that this
 is still out of FOP's hands?

 Thank you for your indulgence,

 rjs


 On 11/05/2012 05:10 PM, Glenn Adams wrote:

 remove elements/attrs until the problem goes away and only comes back when
 adding the element/attr just removed (no matter what else is removed)

 On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent rsarg...@xmission.com wrote:

  I have reviewed the sidebar.fo and it really cannot be substantially
 reduced.  It simply fills the outer edge of our pages - region-start or
 region end - with a narrow two-column, five-row table stretching the length
 of the page.  The inner column is just spacer and the outer column gets the
 section name(s) and number, a rule and a page number.  The names are
 supplied in a rotated svg (not included).







 -
 To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
 For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent

Hopefully this latest one is more direct.

On 11/08/2012 04:00 PM, Glenn Adams wrote:
what i said about maximally minimizing your test FO; when you don't do 
so, you lead devs astray


On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


Please find attached a new fo which defines the sidebar for the
left pages only.  The blue column will show the four lines
separating each row, at least in Evince 3.4.0 (using
poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my
previous statement that I was seeing lines where they should not
be was incorrect. I think they should be there because they are
in the *fo source!

It is true that no lines appear with Adobe, but they are visible
both with Mac's Preview and Linux's Evince. But the lines are
only in the column that does not spans rows, the one with the
blue background. I do not see them in the column that spans rows.
More than that I do not see any unexpected drawing commands in
the PDF source.

Can you please explain again what lines are you seeing in the
printer output? Are they in the blue column or in the white column?

On 11/8/12 5:40 PM, Rob Sargent wrote:
We use iText as well as FOP in producing our printable product. 
Some pages get a black background from iText (certain graphics

look better that way).  When the black background is under the
sidebar (as made with the referenced sidebar.fo
http://sidebar.fo) the nuisance-some inter-cell lines expose
the black underlay. (Our fix is to not put the black under the
sidebar.)

In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't show
up in print,
BTW. To get rid of this on display, go to Acrobat's
Preferences Dialog,
select Page Display and enable Enhance Thin Lines (AR X)
or disable
Smooth line Art. You may have to disable Use 2D graphics
acceleration,
too. Nothing FOP can do at the moment. I've recently
explained on this
list what would need to be done to work around Adobe's
problem.

Since there is a path whereon they do show up in print, I wonder
if this suggested work-around should be revisited? It's not
clear to me that this is still out of FOP's hands?

Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:

remove elements/attrs until the problem goes away and only
comes back when adding the element/attr just removed (no matter
what else is removed)

On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent
rsarg...@xmission.com mailto:rsarg...@xmission.com wrote:

I have reviewed the sidebar.fo http://sidebar.fo and it
really cannot be substantially reduced.  It simply fills
the outer edge of our pages - region-start or region end
- with a narrow two-column, five-row table stretching the
length of the page.  The inner column is just spacer and
the outer column gets the section name(s) and number, a
rule and a page number.  The names are supplied in a
rotated svg (not included).










-
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org
mailto:fop-users-h...@xmlgraphics.apache.org






Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Luis Bernardo


yes, I see the problem. it is indeed strange but I think it is the 
result of the fact that each cell is painted independently and even 
though they touch each other (the common edges of adjacent cells have 
exactly the same coordinates) the viewer (and apparently your printer) 
create an artificial line in between.


maybe this will need to be revisited one day... in any case, in your 
particular example you probably can get around the problem by doing 
things differently. maybe putting the background color in the side 
region instead of giving a background color to the cells of the table.


On 11/8/12 11:03 PM, Rob Sargent wrote:

Hopefully this latest one is more direct.

On 11/08/2012 04:00 PM, Glenn Adams wrote:
what i said about maximally minimizing your test FO; when you don't 
do so, you lead devs astray


On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


Please find attached a new fo which defines the sidebar for the
left pages only.  The blue column will show the four lines
separating each row, at least in Evince 3.4.0 (using
poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my
previous statement that I was seeing lines where they should not
be was incorrect. I think they should be there because they are
in the *fo source!

It is true that no lines appear with Adobe, but they are visible
both with Mac's Preview and Linux's Evince. But the lines are
only in the column that does not spans rows, the one with the
blue background. I do not see them in the column that spans
rows. More than that I do not see any unexpected drawing
commands in the PDF source.

Can you please explain again what lines are you seeing in the
printer output? Are they in the blue column or in the white column?

On 11/8/12 5:40 PM, Rob Sargent wrote:

We use iText as well as FOP in producing our printable
product.  Some pages get a black background from iText (certain
graphics look better that way).  When the black background is
under the sidebar (as made with the referenced sidebar.fo
http://sidebar.fo) the nuisance-some inter-cell lines expose
the black underlay. (Our fix is to not put the black under the
sidebar.)

In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't
show up in print,
BTW. To get rid of this on display, go to Acrobat's
Preferences Dialog,
select Page Display and enable Enhance Thin Lines (AR
X) or disable
Smooth line Art. You may have to disable Use 2D graphics
acceleration,
too. Nothing FOP can do at the moment. I've recently
explained on this
list what would need to be done to work around Adobe's
problem.

Since there is a path whereon they do show up in print, I
wonder if this suggested work-around should be revisited? It's
not clear to me that this is still out of FOP's hands?

Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:

remove elements/attrs until the problem goes away and only
comes back when adding the element/attr just removed (no
matter what else is removed)

On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent
rsarg...@xmission.com mailto:rsarg...@xmission.com wrote:

I have reviewed the sidebar.fo http://sidebar.fo and it
really cannot be substantially reduced. It simply fills
the outer edge of our pages - region-start or region end
- with a narrow two-column, five-row table stretching the
length of the page.  The inner column is just spacer and
the outer column gets the section name(s) and number, a
rule and a page number. The names are supplied in a
rotated svg (not included).










-
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org
mailto:fop-users-h...@xmlgraphics.apache.org








Re: Inter-cell lines no longer spurious pdf viewer problem? RESOLVED

2012-11-08 Thread Rob Sargent
Agree.  As I mentioned in my RESOVED mail, we have remove the underlying 
black which somehow seeped through in Evince and for the print shop.


Thanks for your efforts.  I think there is an issue, but whose it is is 
not clear to me and we think we're past the pain point.


Cheers,

rjs



On 11/08/2012 04:46 PM, Luis Bernardo wrote:


yes, I see the problem. it is indeed strange but I think it is the 
result of the fact that each cell is painted independently and even 
though they touch each other (the common edges of adjacent cells have 
exactly the same coordinates) the viewer (and apparently your printer) 
create an artificial line in between.


maybe this will need to be revisited one day... in any case, in your 
particular example you probably can get around the problem by doing 
things differently. maybe putting the background color in the side 
region instead of giving a background color to the cells of the table.


On 11/8/12 11:03 PM, Rob Sargent wrote:

Hopefully this latest one is more direct.

On 11/08/2012 04:00 PM, Glenn Adams wrote:
what i said about maximally minimizing your test FO; when you don't 
do so, you lead devs astray


On Thu, Nov 8, 2012 at 2:39 PM, Rob Sargent rsarg...@xmission.com 
mailto:rsarg...@xmission.com wrote:


Please find attached a new fo which defines the sidebar for the
left pages only.  The blue column will show the four lines
separating each row, at least in Evince 3.4.0 (using
poppler/cairo(0.18.4))


On 11/08/2012 03:19 PM, Luis Bernardo wrote:


Rob, I looked with more time at this issue and I think that my
previous statement that I was seeing lines where they should
not be was incorrect. I think they should be there because they
are in the *fo source!

It is true that no lines appear with Adobe, but they are
visible both with Mac's Preview and Linux's Evince. But the
lines are only in the column that does not spans rows, the one
with the blue background. I do not see them in the column that
spans rows. More than that I do not see any unexpected drawing
commands in the PDF source.

Can you please explain again what lines are you seeing in the
printer output? Are they in the blue column or in the white column?

On 11/8/12 5:40 PM, Rob Sargent wrote:

We use iText as well as FOP in producing our printable
product.  Some pages get a black background from iText
(certain graphics look better that way).  When the black
background is under the sidebar (as made with the referenced
sidebar.fo http://sidebar.fo) the nuisance-some inter-cell
lines expose the black underlay. (Our fix is to not put the
black under the sidebar.)

In the original thread Jeremias Maerki wrote

I suspect it's once
more Adobe's anti-aliasing to be blamed. And this won't
show up in print,
BTW. To get rid of this on display, go to Acrobat's
Preferences Dialog,
select Page Display and enable Enhance Thin Lines (AR
X) or disable
Smooth line Art. You may have to disable Use 2D
graphics acceleration,
too. Nothing FOP can do at the moment. I've recently
explained on this
list what would need to be done to work around Adobe's
problem.

Since there is a path whereon they do show up in print, I
wonder if this suggested work-around should be revisited? It's
not clear to me that this is still out of FOP's hands?

Thank you for your indulgence,

rjs


On 11/05/2012 05:10 PM, Glenn Adams wrote:

remove elements/attrs until the problem goes away and only
comes back when adding the element/attr just removed (no
matter what else is removed)

On Tue, Nov 6, 2012 at 8:05 AM, Rob Sargent
rsarg...@xmission.com mailto:rsarg...@xmission.com wrote:

I have reviewed the sidebar.fo http://sidebar.fo and it
really cannot be substantially reduced.  It simply fills
the outer edge of our pages - region-start or region
end - with a narrow two-column, five-row table stretching
the length of the page.  The inner column is just spacer
and the outer column gets the section name(s) and number,
a rule and a page number.  The names are supplied in a
rotated svg (not included).










-
To unsubscribe, e-mail:
fop-users-unsubscr...@xmlgraphics.apache.org
mailto:fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail:
fop-users-h...@xmlgraphics.apache.org
mailto:fop-users-h...@xmlgraphics.apache.org










Re: Need help to get Arabic working with FOP

2012-11-08 Thread Brian Hansen
Thank you all for your replies.

I haven't been succesfull in getting the result right. I downloaded
the attached files and tried those, and arabic was displayed using
Arial, I also tried different other fonts such as ScheherazadeRegOT,
but in all cases the letters are not connected correctly, each letter
is displayed standing alone. Also vocal signs are lost even with
ScheherazadeRegOT.

Anyway, I found this application: https://code.google.com/p/wkhtmltopdf/

It uses webkit to convert from HTML to PDF and the result is great
with regard to fonts. No FO file is needed. Links within the PDF file
doesn't work, but I think I can live with that.

I think I'm gonna give up on FOP for now and use webkit HTML to PDF instead.

Best regards.

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: Need help to get Arabic working with FOP

2012-11-08 Thread Glenn Adams
don't give up so easily; send me your input FO file (or a sample) and I'll
check what you are doing wrong... just to make sure, you are using fop 1.1
yes?

note that others are regularly using fop 1.1 successfully for arabic, so it
is probably a usage or config problem on your end

On Thu, Nov 8, 2012 at 4:23 PM, Brian Hansen greencopperm...@gmail.comwrote:

 Thank you all for your replies.

 I haven't been succesfull in getting the result right. I downloaded
 the attached files and tried those, and arabic was displayed using
 Arial, I also tried different other fonts such as ScheherazadeRegOT,
 but in all cases the letters are not connected correctly, each letter
 is displayed standing alone. Also vocal signs are lost even with
 ScheherazadeRegOT.

 Anyway, I found this application: https://code.google.com/p/wkhtmltopdf/

 It uses webkit to convert from HTML to PDF and the result is great
 with regard to fonts. No FO file is needed. Links within the PDF file
 doesn't work, but I think I can live with that.

 I think I'm gonna give up on FOP for now and use webkit HTML to PDF
 instead.

 Best regards.

 -
 To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
 For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org




Re: Need help to get Arabic working with FOP

2012-11-08 Thread Brian Hansen
I have been using FOP 1.0, but never mind, I have just fallin in love
with wkhtmltopdf - the static version produces links inside the PDF
file and the result is so much better than FOP.

Thanks, but I wont be using FOP any longer I think the result from
wkhtmltopdf is much better, even with the problems with Arabic fonts.

2012/11/9, Glenn Adams gl...@skynav.com:
 don't give up so easily; send me your input FO file (or a sample) and I'll
 check what you are doing wrong... just to make sure, you are using fop 1.1
 yes?

 note that others are regularly using fop 1.1 successfully for arabic, so it
 is probably a usage or config problem on your end

 On Thu, Nov 8, 2012 at 4:23 PM, Brian Hansen
 greencopperm...@gmail.comwrote:

 Thank you all for your replies.

 I haven't been succesfull in getting the result right. I downloaded
 the attached files and tried those, and arabic was displayed using
 Arial, I also tried different other fonts such as ScheherazadeRegOT,
 but in all cases the letters are not connected correctly, each letter
 is displayed standing alone. Also vocal signs are lost even with
 ScheherazadeRegOT.

 Anyway, I found this application: https://code.google.com/p/wkhtmltopdf/

 It uses webkit to convert from HTML to PDF and the result is great
 with regard to fonts. No FO file is needed. Links within the PDF file
 doesn't work, but I think I can live with that.

 I think I'm gonna give up on FOP for now and use webkit HTML to PDF
 instead.

 Best regards.

 -
 To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
 For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org




-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org



Re: Need help to get Arabic working with FOP

2012-11-08 Thread Glenn Adams
On Thu, Nov 8, 2012 at 5:11 PM, Brian Hansen greencopperm...@gmail.comwrote:

 I have been using FOP 1.0, but never mind, I have just fallin in love
 with wkhtmltopdf - the static version produces links inside the PDF
 file and the result is so much better than FOP.

 Thanks, but I wont be using FOP any longer I think the result from
 wkhtmltopdf is much better, even with the problems with Arabic fonts.


It can't be better since FOP 1.0 never supported Arabic. You are comparing
apples and oranges. If you wish to try FOP with Arabic, use a version that
supports it. Otherwise, you are wasting our time. Whatever.


java.lang.IllegalArgumentException: 14 when processing math

2012-11-08 Thread tyler
I have three different XML files with a lot of math in them (quantum
physics). With each of them, when I use FOP to generate pdf's I get the
following exception (let me know if you want to see the full stack trace,
here's the top with all the FOP lines):



In one of the files, here is one snippet that will throw the error (it's not
thrown when I comment this out): 



Are there any symbols in there that might be unsupported? Is there something
else I should be considering that might trigger this error? Please let me
know if there is other information I can provide to help track this down.
Thanks in advance for any pointers. 




--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/java-lang-IllegalArgumentException-14-when-processing-math-tp37306.html
Sent from the FOP - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org