Re: fop-users@xmlgraphics.apache.org

[Rob Sargent]

Did you try
initial-page-number="XX"
?

On 09/30/2015 01:34 PM, Franz de Copenhague wrote:

This is my first question to the list.

I did try to google the way to have page numbers with roman numbers 
but I couldn't figure it out.


Would you modify the example below to illustrate me how to achieve 
roman page numbers?



http://www.w3.org/1999/XSL/Format";>

page-height="29.7cm" page-width="21cm" margin-top="1cm" 
margin-bottom="2cm" margin-left="2.5cm" margin-right="2.5cm">








page 


 I would like to see page XX on top 






Thanks,
Franz

Re: page number, but only if more than one page exists

[Rob Sargent]

if you're using xsl transformation... have you tried






On 03/22/2015 10:30 AM, Roberto Nunnari wrote:

Hi.

I need to change a servlet that generates a FO document and then 
transforms it into a pdf document. Unfortunately I know almost nothing 
about Formatting Objects. :-(


At present the FO adds the page number on every page.

I need to change it so that it adds the page number, but only if there 
are more than one page.


fop version in use is very old.. 0.91beta and build-Id is from 20051223

Any help very appreciated.

Thank you and best regards.
Robi

-
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: Upgrading fop 0.95 to fop 1.1 because of PDF/A-1b

[Rob Sargent]

Well you found /most/ of your answer.  Sorry I sent you done fruitless 
rabbit holes.


Can you not embed the full font?  Also isn't Arial supplied by all 
readers as are Times and 2 others (if I recall correctly).


rjs

On 08/21/2014 07:47 AM, MartinKl wrote:

Thank you all for responses and suggestions but it does not resolve problems
which I have.  Patches are applicable on trunk and application on fop v1.1
is not possible since changes in code.  I can not use anything under
development and in general I think modifying stable releases is not the best
practice.

Lets say that I would go over the xmp error with a promisse that next
release will fix it (even the release date hasnt been set up yet) but the
font problem still bothers me.

Any suggestion how to correct the validation error without modifying FOP?



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Upgrading-fop-0-95-to-fop-1-1-because-of-PDF-A-1b-tp41090p41101.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

Re: Loading fonts problem

[Rob Sargent]

Furthermore, the cost of remaining behind the curve is not to be ignored!
On 08/04/2014 10:23 AM, Rob Sargent wrote:
I've had the pleasure of upgrading from .9x to 1.0 (and beyond) and 
the only problem I had with the requirement that each cell in a table 
had an empty block (when of course there is not content).  One solid 
pass through the stylesheets cleaned that up.


rjs

On 08/04/2014 10:18 AM, Chris Bowditch wrote:

Hi Martin,

The preflight warning occurs because the font is only subset, instead 
of fully embedded. In later FOP versions you can specify 
embedding-mode="full" attribute on the font configuration, but that's 
not available in FOP v0.95.


Thanks,

Chris

On 04/08/2014 16:55, MartinKl wrote:

Thank you for your response.

I am trying to generate PDF/A-1b document using FOP 0.95. I know 
that the
version is very old but it is very hard to upgrade because noone 
wants to

pay for it such amount of money for retesting all templates (Bank).

I am struggeling with embedding fonts into pdf file. I get error 
below from

adobe acrobat

<http://apache-fop.1065347.n5.nabble.com/file/n41013/preflight_verification.gif> 




my fop.xconf is here
https://www.dropbox.com/s/42y70t37ttdv5g6/fop.xconf
<https://www.dropbox.com/s/42y70t37ttdv5g6/fop.xconf>

I´ve also created report from adobe acrobat which can be usefull.

https://www.dropbox.com/s/9isf4oo7u0hq6pq/doc_report.pdf
<https://www.dropbox.com/s/9isf4oo7u0hq6pq/doc_report.pdf>

and doc.pdf is here
https://www.dropbox.com/s/y17s2osoljmmh9s/doc.pdf
<https://www.dropbox.com/s/y17s2osoljmmh9s/doc.pdf>


Thank you for response. I hope I´ve provided enough info.

Great Regards
Martin Klapec



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Loading-fonts-problem-tp41009p41013.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






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

Re: Loading fonts problem

[Rob Sargent]

I've had the pleasure of upgrading from .9x to 1.0 (and beyond) and the 
only problem I had with the requirement that each cell in a table had an 
empty block (when of course there is not content). One solid pass 
through the stylesheets cleaned that up.


rjs

On 08/04/2014 10:18 AM, Chris Bowditch wrote:

Hi Martin,

The preflight warning occurs because the font is only subset, instead 
of fully embedded. In later FOP versions you can specify 
embedding-mode="full" attribute on the font configuration, but that's 
not available in FOP v0.95.


Thanks,

Chris

On 04/08/2014 16:55, MartinKl wrote:

Thank you for your response.

I am trying to generate PDF/A-1b document using FOP 0.95. I know that 
the
version is very old but it is very hard to upgrade because noone 
wants to

pay for it such amount of money for retesting all templates (Bank).

I am struggeling with embedding fonts into pdf file. I get error 
below from

adobe acrobat

 




my fop.xconf is here
https://www.dropbox.com/s/42y70t37ttdv5g6/fop.xconf


I´ve also created report from adobe acrobat which can be usefull.

https://www.dropbox.com/s/9isf4oo7u0hq6pq/doc_report.pdf


and doc.pdf is here
https://www.dropbox.com/s/y17s2osoljmmh9s/doc.pdf



Thank you for response. I hope I´ve provided enough info.

Great Regards
Martin Klapec



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Loading-fonts-problem-tp41009p41013.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






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

Re: how to find page numbers while merging more than one PDF

[Rob Sargent]

Or pre-process, getting last page number from the workflow (previous fo 
call), then start next doc one page higher.


On 06/18/2014 02:40 AM, Pascal Sancho wrote:

Hi,

Did you tried the external-document FOP extension [1]?

It's incomplete but could do the trick (not tried, yet).

Other alternative is to post process with third tool like iText [2].

[1] http://xmlgraphics.apache.org/fop/1.1/extensions.html#external-document
[2] http://sourceforge.net/projects/itext/

2014-06-17 17:29 GMT+02:00 Vijaya Raghavan.R :

Hi,

We are generating pdf's separately ,at the end we merge it to single pdf.

(ex: generating three pdf's with 4,8,3 pages respectively. at the end we
merge it to single pdf)

In this case how to find the total page numbers dynamically using
"page-number-citation" .


Please help. Thanks in advance



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/how-to-find-page-numbers-while-merging-more-than-one-PDF-tp40801.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

Re: FOnt config

[Rob Sargent]

copy (or link) each of the ones FOP needs (from your first post) to your 
dir.


That stack trace might be interesting too, since it shouldn't really 
beloading the unreferenced fonts.


On 06/04/2014 11:26 AM, Donald Paul Winston wrote:
There's  a zillion fonts in System/Library/Fonts that Apache FOP does 
not support and I get a stack trace saying I ran out of heap space.


Donald Paul Winston




On Jun 4, 2014, at 1:12 PM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:



system default directory

Re: FOnt config

[Rob Sargent]

Don't worry about the metrics.
Add the system default directory. (Last I saw you were not finding Times 
Roman.)



On 06/04/2014 10:59 AM, Donald Paul Winston wrote:

My fop.xconf is has the following:


  

flate







  

  
/Users/satchwinston/fonts
…….
…….

I use the ./fop -c conf/fop.xconf …   and it still can’t find it 
font-family=“Code39” (Code39.pfa / Code39.afm)


Do I need to setup a font metrics file? And then configure for that?

Donald Paul Winston




On Jun 4, 2014, at 12:17 PM, Donald Paul Winston 
> wrote:



FOP 0.20.5

oops, I don’t know where I got this. I see FOP 1-1 has an fop.xconf 
file which jives with what I see in the examples.





On Jun 4, 2014, at 12:06 PM, Amick, Eric > wrote:


I use auto-detect with no difficulty, and I'm sure plenty of people 
use the other features as well. Which version of FOP are you using? 
You should probably post the actual config file you're using.


-Original Message-
From: Donald Paul Winston [mailto:satchwins...@yahoo.com]
Sent: Wednesday, June 04, 2014 11:56
To: fop-users@xmlgraphics.apache.org 


Subject: Re: FOnt config

This does not work.



 C:\MyFonts1


 C:\MyFonts2


 


the DTD does not support "directory" or "auto-detect"



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/FOnt-config-tp40743p40744.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 




-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org 

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

Re: Failed to Transform Due to Handler Issue

[Rob Sargent]

Can you show us your FO document?
On 05/16/2014 06:41 AM, rushabh wrote:

I am getting error while running a test case regarding Handler issue.
Can you help me ?

Here is a code :-

*A Method which returns a ContentHandler :-*

  protected ContentHandler getRendererAsHandler(
 final OutputStream anOutputStream)
throws ReportException
{

FOUserAgent foUserAgent = fopFactory.newFOUserAgent();  

ContentHandler ch = null;

try {

Fop fop =
fopFactory.newFop(MimeConstants.MIME_PDF,foUserAgent,anOutputStream);
  ().createDocumentHandler(foUserAgent, 
"application/pdf");
ch = fop.getDefaultHandler();   

} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

return ch;  
}


*A class that calls above method and transform into PDF or printable format
:-*

ContentHandler handler = (ContentHandler)
 getRendererAsHandler(anOutputStream);

SAXTransformerFactory tFactory =
(SAXTransformerFactory)SAXTransformerFactory.newInstance();
 Transformer transformer = tFactory.newTransformer();

 final SAXSource inputSource =
 new SAXSource(this.xmlReader, new
InputSource(reportStream));
 
 
* transformer.transform(inputSource, new SAXResult(handler));*


On this line i am getting error like unable to transform : -

ReportException:Failed to transform report
Caused by:
javax.xml.transform.TransformerException:
org.apache.fop.fo.ValidationException: First element must be the fo:root
formatting object. Found (Namespace URI:
"http://www.xx.com/xx/ReportTemplate";, Local Name: "reportTemplate")
instead. Please make sure you're producing a valid XSL-FO document.
  
On debug i got FOTreeBuilder object instead ContentHandler object , Thats

why i think it caused error, I also tried to type cast it but not working
properly.
  
I konw it is some silly mistake but i am new to FOP , So can't able to

resolve it.



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Failed-to-Transform-Due-to-Handler-Issue-tp40613.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




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

Re: preserving a trailing space in inline

[Rob Sargent]

This has worked for me

  

select="concat('(Left)',' ')"/>


   
 

On 05/19/2014 09:25 PM, Terence M. Bandoian wrote:

On 5/19/2014 10:03 PM, Jason Harrop wrote:

Hi Terence,  thanks, it's good to know the simple FO works fine!

Its non trivial for me to get rid of the inline elements, although I
could get rid of the nested ones if it is these which are causing the
problem.

I'll look into that, but it would still be useful to get confirmation
as to which of the whitespace attributes I should be using.

thanks .. Jason



Hi, Jason-

Both fo:page-number and fo:page-number-citation-last are documented to 
support padding so you might look into that if you can't determine why 
the white space is collapsing.


Good luck!

-Terence Bandoian

-
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: Nested Bulleted Lists Problem

[Rob Sargent]

Just occurs to me your starting point is HTML so your mileage will definitely 
vary. Sorry. 

Sent from my iPhone

> On Apr 5, 2014, at 9:05 AM, Rob Sargent  wrote:
> 
> If you don't switch over to the style sheet Manuel points us to, then might 
> try something like below which gets include in the actual style sheet ( 
> ).
> 
> Couple of notes:
> the "ElementConversion" is noise
> your test will be 
> choose you own actual bullet character, hopefully you're using a modern, 
> complete font
> 
> 
> As I said earlier, they're rendered in a single list, as seen in the calls at 
> the bottom. Luckily I know there are only four levels. If you don't have that 
> knowledge you might have to recurse. In xsl. Oh what fun.
> 
> 
> http://www.w3.org/1999/XSL/Transform";
> xmlns:ec="xalan://com.employer.utilities.ElementConversion"
> xmlns:fo="http://www.w3.org/1999/XSL/Format";
> xmlns:xalan="http://xml.apache.org/xslt";>
> 
> 2.3pt
> 10pt
> 17pt
> 25pt
> •
> ◦
> ▪
> –
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  font-style="normal">
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> And here is the call. This particular caller only goes down 3.
> 
> 
> 
> 
>  provisional-distance-between-starts="8.0pt" 
> provisional-label-separation="0.1pt">
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>> On 04/04/2014 09:36 PM, Manuel Mall wrote:
>>> On 4/4/2014 8:25 PM, a3leggeddog wrote:
>>> Hi Terence -
>>> 
>>> Thank you for your quick response!  I thought I tried that as well,
>>> but I will give it another shot.  Do you have an XSL template that
>>> will produce the correct XML-FO from HTML for nested lists?
>>> 
>>> Thanks,
>>> Seth
>> Do a Google search for 'HTML 2 FO' or similar and you'll find a number
>> of solutions. For example Antenna House publishes a free HTML to FO
>> conversion stylesheet, i.e. on
>> http://www.antennahouse.com/XSLsample/XSLsample.htm you see a link to
>> http://www.antennahouse.com/XSLsample/sample-xsl-xhtml2fo/xhtml2fo.xsl
>> half way down the page in the section titled "Stylesheet for XHTML to
>> XSL-FO transformation".
>> 
>> Manuel
>> 
>> -
>> 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
> 

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

Re: Nested Bulleted Lists Problem

[Rob Sargent]

If you don't switch over to the style sheet Manuel points us to, then 
might try something like below which gets include in the actual style 
sheet ( ).


Couple of notes:
the "ElementConversion" is noise
your test will be 
choose you own actual bullet character, hopefully you're using a modern, 
complete font



As I said earlier, they're rendered in a single list, as seen in the 
calls at the bottom. Luckily I know there are only four levels. If you 
don't have that knowledge you might have to recurse. In xsl. Oh what fun.



xmlns:xsl="http://www.w3.org/1999/XSL/Transform";

xmlns:ec="xalan://com.employer.utilities.ElementConversion"
xmlns:fo="http://www.w3.org/1999/XSL/Format";
xmlns:xalan="http://xml.apache.org/xslt";>

2.3pt
10pt
17pt
25pt
•
◦
▪
–







































font-style="normal">










 











And here is the call. This particular caller only goes down 3.




provisional-distance-between-starts="8.0pt" 
provisional-label-separation="0.1pt">
























On 04/04/2014 09:36 PM, Manuel Mall wrote:

On 4/4/2014 8:25 PM, a3leggeddog wrote:

Hi Terence -

Thank you for your quick response!  I thought I tried that as well,
but I will give it another shot.  Do you have an XSL template that
will produce the correct XML-FO from HTML for nested lists?

Thanks,
Seth

Do a Google search for 'HTML 2 FO' or similar and you'll find a number
of solutions. For example Antenna House publishes a free HTML to FO
conversion stylesheet, i.e. on
http://www.antennahouse.com/XSLsample/XSLsample.htm you see a link to
http://www.antennahouse.com/XSLsample/sample-xsl-xhtml2fo/xhtml2fo.xsl
half way down the page in the section titled "Stylesheet for XHTML to
XSL-FO transformation".

Manuel

-
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: Nested Bulleted Lists Problem

[Rob Sargent]

Think of it as one list, with various indents and bullet-types according 
to the nestedness of your input.


I have examples (at home) if you need them - to four bullet levels

On 04/04/2014 06:49 PM, a3leggeddog wrote:

Hello -

I am trying to convert a nested, bulleted list in HTML to XML-FO for output
as a PDF in Apache FOP. The HTML looks like this


Item Number1
   
   Sub-Item 1
   Sub-Item 2
   
  

All of the XSLT I have tried creates a with an embedded for the subitems.
FOP, however, complains that you can't have a list-block as a child of a
list-block. Is this an issue with FOP? Or, is that simply not valid XML-FO
and all of the XSLT examples are processing this construct incorrectly?

If it's the later, what is the proper XML-FO to produce a nested set of
bullets like you would see in HTML?

Any help would be greatly appreciated!

Thanks!



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Nested-Bulleted-Lists-Problem-tp40436.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

Re: why the xml and xsl files have to be in the bin folder of tomcat when I generate a application web for that the application works?

[Rob Sargent]

Move them to the app root?

On 04/03/2014 11:57 AM, edi4988 wrote:

Do you know what can I do if my files have this path
http://localhost:8080/XML/SIICG.xml ?

Thanx



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/why-the-xml-and-xsl-files-have-to-be-in-the-bin-folder-of-tomcat-when-I-generate-a-application-web-f-tp40348p40422.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

Re: logging page number

[Rob Sargent]

Then too, if FOP reporting something like

   "on or after page N" we see that a paragraph overflows the available
   area by more than 50 points. (See position 344:409)"

might be all the OP really needs.


On 03/27/2014 06:03 PM, Rob Sargent wrote:
I'm starting to suspect the OP and crew are editing the content to fit 
the format. If that is the case, it might be worth the time to hack up 
a tool which goes to that line in the fo. Failing that the crew is 
left pouring over pdfs looking for bad formatting. In this case, in 
the test runs I would change the background colour of the region 
getting the overflow so the overflowing content shows up better. Or 
sometimes truncating the overflow is enough to show the problem. Still 
pretty manual though. Use the fo, luke.


Have we seen what sorts of block and regions are involved?

On 03/27/2014 05:51 PM, Luis Bernardo wrote:


It is not possible to get the page number where the overflow happens, 
and it would be tricky to implement. When the overflow happens during 
line breaking the page breaking has not happened yet so it is not 
known at that stage in what page it will happen.


In any case, there are 72 points in an inch so you just have to take 
that in consideration when deciding whether to check the overflow 
visually.


On 3/27/14, 10:50 PM, natk wrote:
Yes, it is the position in the FO file (as I said in the original 
post) but if the page information was available to print in the log 
message, that would make fixing this errors so much easier 
(especially for those on my team who aren't expert in trawling 
through FO files).


Thanks.


On Fri, Mar 28, 2014 at 12:38 AM, rsargent [via Apache FOP] <[hidden 
email] > wrote:


Isn't that line number in your FO file?

Sent from my iPhone

> On Mar 26, 2014, at 8:44 PM, natk <[hidden email]
<http://user/SendEmail.jtp?type=node&node=40356&i=0>> wrote:
>
> Is it possible to configure FOP logging to print page number
information?
>
> I get lots of the following messages:
>
> 2014-03-27 13:17:51,072  WARN
> (org.apache.fop.events.LoggingEventListener:97) - Line 1 of a
paragraph
> overflows the available area by more than 50 points. (See
position 344:409)
>
> I can search the fo file at that position, but it would be so
much easier if
> I knew the output page, then I could go straight to that page
and check the
> overflow.
>
>
>
> --
> View this message in context:
http://apache-fop.1065347.n5.nabble.com/logging-page-number-tp40352.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
-

> To unsubscribe, e-mail: [hidden email]
<http://user/SendEmail.jtp?type=node&node=40356&i=1>
> For additional commands, e-mail: [hidden email]
<http://user/SendEmail.jtp?type=node&node=40356&i=2>
>

-

To unsubscribe, e-mail: [hidden email]
<http://user/SendEmail.jtp?type=node&node=40356&i=3>
For additional commands, e-mail: [hidden email]
<http://user/SendEmail.jtp?type=node&node=40356&i=4>




If you reply to this email, your message will be added to the
discussion below:

http://apache-fop.1065347.n5.nabble.com/logging-page-number-tp40352p40356.html

To unsubscribe from logging page number, click here.
NAML

<http://apache-fop.1065347.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>





View this message in context: Re: logging page number 
<http://apache-fop.1065347.n5.nabble.com/logging-page-number-tp40352p40366.html>
Sent from the FOP - Users mailing list archive 
<http://apache-fop.1065347.n5.nabble.com/FOP-Users-f3.html> at 
Nabble.com.

Re: logging page number

[Rob Sargent]

I'm starting to suspect the OP and crew are editing the content to fit 
the format. If that is the case, it might be worth the time to hack up a 
tool which goes to that line in the fo. Failing that the crew is left 
pouring over pdfs looking for bad formatting. In this case, in the test 
runs I would change the background colour of the region getting the 
overflow so the overflowing content shows up better. Or sometimes 
truncating the overflow is enough to show the problem. Still pretty 
manual though. Use the fo, luke.


Have we seen what sorts of block and regions are involved?

On 03/27/2014 05:51 PM, Luis Bernardo wrote:


It is not possible to get the page number where the overflow happens, 
and it would be tricky to implement. When the overflow happens during 
line breaking the page breaking has not happened yet so it is not 
known at that stage in what page it will happen.


In any case, there are 72 points in an inch so you just have to take 
that in consideration when deciding whether to check the overflow 
visually.


On 3/27/14, 10:50 PM, natk wrote:
Yes, it is the position in the FO file (as I said in the original 
post) but if the page information was available to print in the log 
message, that would make fixing this errors so much easier 
(especially for those on my team who aren't expert in trawling 
through FO files).


Thanks.


On Fri, Mar 28, 2014 at 12:38 AM, rsargent [via Apache FOP] <[hidden 
email] > wrote:


Isn't that line number in your FO file?

Sent from my iPhone

> On Mar 26, 2014, at 8:44 PM, natk <[hidden email]
> wrote:
>
> Is it possible to configure FOP logging to print page number
information?
>
> I get lots of the following messages:
>
> 2014-03-27 13:17:51,072  WARN
> (org.apache.fop.events.LoggingEventListener:97) - Line 1 of a
paragraph
> overflows the available area by more than 50 points. (See
position 344:409)
>
> I can search the fo file at that position, but it would be so
much easier if
> I knew the output page, then I could go straight to that page
and check the
> overflow.
>
>
>
> --
> View this message in context:
http://apache-fop.1065347.n5.nabble.com/logging-page-number-tp40352.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
-

> To unsubscribe, e-mail: [hidden email]

> For additional commands, e-mail: [hidden email]

>

-

To unsubscribe, e-mail: [hidden email]

For additional commands, e-mail: [hidden email]





If you reply to this email, your message will be added to the
discussion below:

http://apache-fop.1065347.n5.nabble.com/logging-page-number-tp40352p40356.html

To unsubscribe from logging page number, click here.
NAML







View this message in context: Re: logging page number 

Sent from the FOP - Users mailing list archive 
 at 
Nabble.com.

Re: Alternating background-color for table rows, but always restart on page break

[Rob Sargent]

Over what are you iterating? ie. to what is position() referring?

Sent from my iPhone

> On Mar 27, 2014, at 7:55 AM, Frank Hirsch  wrote:
> 
> It's easy to toggle to background color of table rows in XSLT using "mod":
> 
> 
>   
>   
>   
>   #ff
>   
>   
>   #cc
>   
>   
>   
>   ...
> 
> 
> Unfortunately this does not match my current requirement and can not be 
> solved in XSLT which does not now of page breaks:
> I need to start each page with "#cc" - espacially if there is a page 
> break and the table will be continued on the next page.
> 
> Any ideas?

Re: logging page number

[Rob Sargent]

Isn't that line number in your FO file?

Sent from my iPhone

> On Mar 26, 2014, at 8:44 PM, natk  wrote:
> 
> Is it possible to configure FOP logging to print page number information?
> 
> I get lots of the following messages:
> 
> 2014-03-27 13:17:51,072  WARN
> (org.apache.fop.events.LoggingEventListener:97) - Line 1 of a paragraph
> overflows the available area by more than 50 points. (See position 344:409)
> 
> I can search the fo file at that position, but it would be so much easier if
> I knew the output page, then I could go straight to that page and check the
> overflow.
> 
> 
> 
> --
> View this message in context: 
> http://apache-fop.1065347.n5.nabble.com/logging-page-number-tp40352.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
> 

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

Re: Multiples Pages

[Rob Sargent]

What is your current stack for going from data (source xml) to fo?

My first guess is that either you combine source docs into single fo.  
An alternative is to post-process the pdfs with something like iText.



On 02/10/2014 03:09 PM, edi4988 wrote:

Thanks for the reply

But I need to generate a Pdf file with a XSLT template and I have "n" XML
data files like source and the pdf file has a page for every xml file.

Do You have any idea like I can use the XSLT document() function?

Thanks.





--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Multiples-Pages-tp40001p40041.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

Re: fo:table-row bleeds into footer

[Rob Sargent]

Wonderful news.

You might add not-blank back in to the "lasts".

On 02/10/2014 08:14 AM, Bonekrusher wrote:

Actually I think Its working. I believe that what I was reporting as "bad" is
actually not. Because the footers are different sizes, its possible to leave
a flow with no content on the last page, if the previous page's content goes
past a certain point.



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40035.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

Re: fo:table-row bleeds into footer

[Rob Sargent]

HAppy to help. Happy to help more. Do not settle for less than perfect. Send 
latest FO 

Sent from my iPhone

> On Feb 9, 2014, at 3:39 PM, Bonekrusher  wrote:
> 
> First, I want to say thank you for all the help. I really appreciate it. Your
> solution seems to work most of the time. I did notice that the page breaking
> is a little off from going from 2-3 pages, which leaves a gap and the bottom
> of the flow and the last page's flow is empty. Nevertheless, I think I can
> live with that as I don't expect to have more than 2 pages ever. 
> 
> Thanks again! 
> 
> 
> 
> --
> View this message in context: 
> http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40023.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
> 

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

Re: fo:table-row bleeds into footer

[Rob Sargent]

I should have gone to the docs straight away - been away too long- but 
"rest" is what you want not "any"


This I think works the way you want:




master-reference="page" page-position="first"/>
master-reference="page" page-position="rest"/>
master-reference="page-last" page-position="last"/>



page-width="8.5in" margin-top="0.25in" margin-bottom="0in" 
margin-left="0.25in" margin-right=".25in">
margin-top="3.55in" margin-bottom="1.70in"/>
extent="1in"/>
extent="1.55in" background-color="yellow"/>


page-height="11in" page-width="8.5in" margin-top="0.25in" 
margin-left="0.25in" margin-right=".25in" margin-bottom="0in">
margin-top="3.55in" margin-bottom="4.00in"/>
extent="3.55in"/>
extent="3.75in" background-color="orange"/>





On 02/09/2014 10:40 AM, Rob Sargent wrote:

Drop the blank constraint for one. I am not where I can re-read precedence of conditional 
pages. It is possible you have hit a bug - there at least one out for "last" 
but I don't think this is related.

Sent from my iPhone


On Feb 9, 2014, at 10:18 AM, Bonekrusher  wrote:

Thanks for helping. I guess I need help with what would be next. If I have:







doesn't that cover first, rest and last. What else could there be?



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40017.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


-
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: fo:table-row bleeds into footer

[Rob Sargent]

ust notice in your original fo that both region-before have same name.  
I thought that would generate an error by itself but apparently not. I 
could confuse things though.


On 02/09/2014 10:40 AM, Rob Sargent wrote:

Drop the blank constraint for one. I am not where I can re-read precedence of conditional 
pages. It is possible you have hit a bug - there at least one out for "last" 
but I don't think this is related.

Sent from my iPhone


On Feb 9, 2014, at 10:18 AM, Bonekrusher  wrote:

Thanks for helping. I guess I need help with what would be next. If I have:







doesn't that cover first, rest and last. What else could there be?



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40017.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


-
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: fo:table-row bleeds into footer

[Rob Sargent]

This p-s-m does NOT generate Exception, does generate 5th page.




master-reference="page-last" blank-or-not-blank="not-blank" 
page-position="last"/>
odd-or-even="even" master-reference="page-last" 
blank-or-not-blank="not-blank" page-position="last"/>
master-reference="page" page-position="any"/>





On 02/09/2014 10:40 AM, Rob Sargent wrote:

Drop the blank constraint for one. I am not where I can re-read precedence of conditional 
pages. It is possible you have hit a bug - there at least one out for "last" 
but I don't think this is related.

Sent from my iPhone


On Feb 9, 2014, at 10:18 AM, Bonekrusher  wrote:

Thanks for helping. I guess I need help with what would be next. If I have:







doesn't that cover first, rest and last. What else could there be?



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40017.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


-
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: fo:table-row bleeds into footer

[Rob Sargent]

Drop the blank constraint for one. I am not where I can re-read precedence of 
conditional pages. It is possible you have hit a bug - there at least one out 
for "last" but I don't think this is related. 

Sent from my iPhone

> On Feb 9, 2014, at 10:18 AM, Bonekrusher  wrote:
> 
> Thanks for helping. I guess I need help with what would be next. If I have:
> 
>  master-reference="page" blank-or-not-blank="not-blank"
> page-position="first"/>
>  master-reference="page" blank-or-not-blank="not-blank"
> page-position="first"/>
>  master-reference="page-odd" blank-or-not-blank="not-blank"
> page-position="rest"/>
>  master-reference="page-even" blank-or-not-blank="not-blank"
> page-position="rest"/>
>  master-reference="page-last" blank-or-not-blank="not-blank"
> page-position="last"/>
> 
> doesn't that cover first, rest and last. What else could there be?
> 
> 
> 
> --
> View this message in context: 
> http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40017.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
> 

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

Re: fo:table-row bleeds into footer

[Rob Sargent]

Did you try colors? Are you regenerating FO with each change - not that that 
should be necessary... If I read the error correctly fop doesn't know what to 
"next".

Sent from my iPhone

> On Feb 9, 2014, at 5:33 AM, Bonekrusher  wrote:
> 
> I've tried a number of page different "page-sequence-master" sequences and
> they all seem to result in an
> "org.apache.fop.fo.pagination.PageProductionException: Subsequences
> exhausted in page-sequence-master". Below is an example.
> 
> 
>
>
> master-reference="page" blank-or-not-blank="not-blank"
> page-position="first"/>
> master-reference="page" blank-or-not-blank="not-blank"
> page-position="first"/>
> master-reference="page-odd" blank-or-not-blank="not-blank"
> page-position="rest"/>
> master-reference="page-even" blank-or-not-blank="not-blank"
> page-position="rest"/>
> master-reference="page-last" blank-or-not-blank="not-blank"
> page-position="last"/>
>
>
> page-width="8.5in" margin-top="0.25in" margin-bottom=".250in"
> margin-left="0.25in" margin-right=".25in">
> margin-bottom="1.0in"/>
>
>
>
> page-width="8.5in" margin-top="0.25in" margin-bottom=".250in"
> margin-left="0.25in" margin-right=".25in">
> margin-bottom="1.0in"/>
>
>
>
> page-width="8.5in" margin-top="0.25in" margin-bottom=".250in"
> margin-left="0.25in" margin-right=".25in">
> margin-bottom="1.0in"/>
>
>
>
> page-width="8.5in" margin-top="0.25in" margin-left="0.25in"
> margin-right=".25in" margin-bottom=".250in">
> margin-bottom="3.65in"/>
>
>
>
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40015.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
> 

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

Re: fo:table-row bleeds into footer

[Rob Sargent]

I can see with orig. bottom margin that it was right about last page. I would 
play with pageSequenceMaster entries. I would use diff. background colours in 
each pageMaster to see which are actually in play and when.

> On Feb 8, 2014, at 4:27 PM, Bonekrusher  wrote:
> 
> Thanks - I will have a minimum if 1 and mostly likely a max of 4 or 5. I'll
> try to add a definition for what's to come after "page-last". I assume since
> page-last is last, but needs to calculate? 
> 
> 
> 
> --
> View this message in context: 
> http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40011.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
> 

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

Re: fo:table-row bleeds into footer

[Rob Sargent]

I think it doesn't have a page definition for what's to come after 
"page-last".  As I see it there's some confusion about last page.  The 
data you presented in fact needs to go to the next page so I don't think 
you conditional pages is quite right.


I've had many layouts with different margin-bottoms.

Do you know the minimum number of pages you expect?  If so make specific 
page-sequence-masters for that situation, then add the variable 
page-sequence you have now.




On 02/08/2014 10:48 AM, Bonekrusher wrote:

same here - its seems if the simple-page-master's "margin-bottom" for all
pages and the simple-page-master's "margin-bottom" for the last page are
different sizes, it throws an exception
"org.apache.fop.fo.pagination.PageProductionException: Subsequences
exhausted in
page-sequence-master "invoice", cannot recover". This doesn't make sense to
me because the last page is allowed to have it own set of properties.

I'm am thinking this is a bug.



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40009.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




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

Re: fo:table-row bleeds into footer

[Rob Sargent]

What do you get if you change margin-bottom to 3.75in on page-last 
simple-page-master? I think that's the mismatch, but for me that causes 
an fop exception (but I only have 1.0 here)


rjs




On 02/08/2014 06:16 AM, Bonekrusher wrote:

Thank you - I've been working on this for hours and can't seem to figure out
the solution. I've adjusted the footer sizes and margins but still no luck.
Below is a link to download a working example. I kept it as simple as
possible. I appropriate any help.

FO Sample - Bleed Issue 



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003p40007.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




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

Re: fo:table-row bleeds into footer

[Rob Sargent]

If you can trap the actual fo you will likely see an errant combination 
for static regions. I'm betting some page doesn't match body and footer 
size.



On 02/07/2014 02:22 PM, Bonekrusher wrote:

Hi,

I am using FOP 1.1. I have the following page layout. Basically the last
page's footer (either odd or even) will have a big footer. The issue I am
having is if I have a table, the rows bleed into the last-page-even footer
(xsl-region-after-last) when it should break to 3rd page. My
xsl-region-after-last is large (3.75in).

Any ideas on how I can resolve this?





































--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/fo-table-row-bleeds-into-footer-tp40003.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

Re: Batch output

[Rob Sargent]

I had good results stitching them together with iText.

rjs

On 11/21/2013 02:11 PM, Gonzalo Vasquez wrote:
One of our processes has to deal with thousands of documents in a 
batch process, either for email sending, or for printing.


Depending on our customers' needs, we choose from PDF, AFP and PS as 
output formats. Now we are trying to move everything to FO generated 
documents, so we can you a single template for all output formats.


Several questions arise:

 1. On the email process (many files as output), do I have to deal
with every document in a separate context, or is there any
fo-related trick to achieve this in a better way?
 2. In the printing process (single file output), is there anyway to
feed the template just once for all documents and the "add" the
data to get a huge document with all the subdocuments in it?


Any other ideas for such batch processing?

Any comments will be of great help!


Regards,




Gonzalo Vásquez Sáez
Gerente Investigación y Desarrollo (R&D)
Altiuz Soluciones Tecnológicas de Negocios Ltda.
Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
+56 2 335 2461
gvasq...@altiuz.cl 
http://www.altiuz.cl
http://www.altiuzreports.com
	  

Re: Content overflows the viewport

[Rob Sargent]

You only get meaningful line numbers if you're running fo directly, not 
in any sort of pipeline where the input fo file is a stream.


On 11/19/2013 04:45 PM, Luis Bernardo wrote:


Are you using trunk?

I get this with trunk:

Nov 19, 2013 11:42:05 PM org.apache.fop.events.LoggingEventListener 
processEvent
WARNING: Content overflows the viewport of an fo:block-container in 
inline-progression direction by 54 millipoints. Content will be 
clipped. (See position 490:64)



Position 490:64, is line 490, character position 64.


On 11/18/13, 4:05 PM, Gonzalo Vasquez wrote:

I'm getting several warnings like these:

Nov 18, 2013 12:58:40 PM org.apache.fop.events.LoggingEventListener 
processEvent
Advertencia: Content overflows the viewport of an fo:block-container 
in inline-progression direction by 54 millipoints. Content will 
be clipped. (No context info available)


How can I properly identify the offending elements? Please consider 
that the FO is XSL generated.


Regards,

Gonzalo Vásquez Sáez
Gerente Investigación y Desarrollo (R&D)
Altiuz Soluciones Tecnológicas de Negocios Ltda.
Av. Nueva Tajamar 555 Of. 802, Las Condes - CP 7550099
+56 2 335 2461
gvasq...@altiuz.cl 
http://www.altiuz.cl
http://www.altiuzreports.com
	  

Re: Maven + FOP 1.1

[Rob Sargent]

Off list, as this a work-around suggestion:  Can you convince local 
administrators to simply add the jar(s) to your local maven cache?


rjs

On 11/18/2013 01:00 PM, Arian wrote:

Hey all,
I'm a web developer that has to create a quick Servlet as a proof of 
concept but our project uses Maven and FOP 1.1 seems to be broken 
in Maven possibly.


I added this to the pom.xml:

org.apache.xmlgraphics
fop
1.1



and when I run the Maven install i get:

[ERROR] Failed to execute goal on project mytest: Could not resolve 
dependencies for project com.testwebsite.mytest:war:1.4.0: The 
following artifacts could not be resolved: 
org.apache.avalon.framework:avalon-framework-api:jar:4.2.0, 
org.apache.avalon.framework:avalon-framework-impl:jar:4.2.0: Failure 
to find org.apache.avalon.framework:avalon-framework-api:jar:4.2.0 in 
http://repo1.maven.org/maven2 was cached in the local repository, 
resolution will not be reattempted until the update interval of 
central has elapsed or updates are forced




I read something in a thread in December about how the maven FOP 1.1 
repository should be fixed. But not sure what the solution people came 
up with.

P.S. we don't have a Maven Repository Manager system :(. Any ideas?

Thanks for any advice,
Ari

Re: Floating an image (block right and wrap text)?

[Rob Sargent]

Sorry did mean to send it off-list, honest :)

On 11/04/2013 03:14 PM, Rob Sargent wrote:

Taking this off the list.

I just think the textgeneration is a separate problem form getting 
pictures into the product. Once canmake all sorts of constraints on 
where the text goes without including any images.


rjs


Generally theregions for each are carved out of the whole and
On 11/04/2013 03:06 PM, Jeffrey Walton wrote:

On Mon, Nov 4, 2013 at 4:59 PM, Rob Sargent  wrote:

I've always assumed typesetting was about type, not pictures.

When's the last time you saw a newspaper, magazine, or catalog without
a picture?

Jeff


Its hard to believe placing an image is considered extended
functionality. That's part of core word processing functionality (I
can't comment on typesetting because I'm not a typesetter, but I
suspect its core for them, too).

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

Re: Floating an image (block right and wrap text)?

[Rob Sargent]

Taking this off the list.

I just think the textgeneration is a separate problem form getting 
pictures into the product. Once canmake all sorts of constraints on 
where the text goes without including any images.


rjs


Generally theregions for each are carved out of the whole and
On 11/04/2013 03:06 PM, Jeffrey Walton wrote:

On Mon, Nov 4, 2013 at 4:59 PM, Rob Sargent  wrote:

I've always assumed typesetting was about type, not pictures.

When's the last time you saw a newspaper, magazine, or catalog without
a picture?

Jeff


Its hard to believe placing an image is considered extended
functionality. That's part of core word processing functionality (I
can't comment on typesetting because I'm not a typesetter, but I
suspect its core for them, too).

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

Re: Floating an image (block right and wrap text)?

[Rob Sargent]

I've always assumed typesetting was about type, not pictures.

Thanks Alexey.

Its hard to believe placing an image is considered extended
functionality. That's part of core word processing functionality (I
can't comment on typesetting because I'm not a typesetter, but I
suspect its core for them, too).

Jeff





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

Re: Transforming Incompatible Stylesheets over to FOP Apache

[Rob Sargent]

Is it possible to get any informative error messages out of "Arbortext 
Publisher app" when using anArmy xsl.


It's easy enough to understand that the resultant pdf doesn't match 
S1000D, but is Arbortext detecting those differences or is it actually 
failing to generate because of xsl transformation errors.


My guess is your best bet is #2.  Sounds like that will be an achievable 
list of changes, no?


I really don't follow the notion of "FOP Apache stylesheet coding 
conventions".  The xsl tags are in the identified namespace. Same for 
the fo tags. Isn't that the end of the story? (Until you hit errors like 
trying to but a fo:table-row out without an enclosing fo:table etc)





On 10/30/2013 07:55 PM, matrix wrote:

Thanks for your post Rsargent.

It makes sense that after looking at a few the Army stylesheets located in
the link I provided you are pointing out they speak directly to S1000D. The
MIL-SPEC-3031A is actually the Army's version of the S1000D standard.  The
Army borrows from the S1000D standard a lot of stylesheet related code.
However, there are some differences on how the PDF looks like on paper. For
example the 3031A standard requires the ICN number for a graphic appear on
the lower right hand corner of a graphic.  In contrast, the S1000D standard
does not require the ICN number display on the page at all. Like this
example, there are a bunch of other stylesheet related differences between
the 3031A standard and S1000D standard that are too numerous to cover.

Therefore, I somehow need to make the 3031A stylesheets I got from the Army
work in harmony with my Arbortext Publisher app because currently it doesn't
recognize them at all. It only recognizes the S1000D standard stylesheets
that were included with Arbortext Publisher.  From what I was told by the
Arbortext technical support person the 3031A stylesheets are not compatible
with Arbortext Publisher because they are not correctly coded to FOP Apache
stylesheet coding conventions. My stylesheet coding skills are not strong
enough to figure out how the 3031A stylesheet code deviates from FOP Apache
stylesheet code. Therefore, I would be very grateful if anyone out there can
take a good look at the XSL files inside the 3031A ZIP file and let me know
how this code deviates from FOP Apache stylesheet coding conventions.

In closing, the way I see it is I need to do one of two things:

1. Find a FOP Apache transformation engine that will transform my 3031A
stylesheets to a format my Arbortext Publisher app likes.

2. I need to figure out how to modify the code to the existing S1000D FOP
Apache stylesheets my Arborext Publisher app uses so that it follows all of
the formatting rules the Army 3031A standard requires.

Any info or suggestions that will help me make progress will be greatly
appreciated. Thanks.







--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Transforming-Incompatible-Stylesheets-over-to-FOP-Apache-tp39504p39507.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




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

Re: Transforming Incompatible Stylesheets over to FOP Apache

[Rob Sargent]

I only looked at a couple Army style sheets.  What is it about them 
which you find "not coded to the FOP Apache standard". I see one which 
speaks directly to the S1000D spec.


On 10/30/2013 03:48 PM, matrix wrote:

Fellow Forum Members,
I'm using Arbortext Publisher which utilizes FOP Apache coded stylesheets to
output a PDF compliant to the S1000D standard. However, I need to have my
PDF publication conform to an Army military standard known as MIL-SPEC
3031A. These 3031A stylesheets are available for free download at the link
below:

https://www.logsa.army.mil/pub/s1000d/FO-3031-A00-USARMY-PARA_001-00_EN-US.zip

My problem is a compatability related problem. The 3031A stylesheets the
Army provides are not coded to the FOP Apache standard and therefore
incompatible with Arbortext Publisher. In short, I'm not able to output my
publication out of Arbortext Publisher as a 3031A compliant PDF.

Since I'm new to FOP Apache, I'm hoping anybody out there can outline a
strategy on what I need to do to convert the Army provided 3031A stylesheets
over to FOP Apache stylesheets?

Is there a transformation engine that accomplishes this task?

Also, are there any online training videos that show how to modify FOP
Apache stylesheet code? My thinking is maybe I could tweak the code so that
my PDF outputs as something that looks close to a 3031A compliant
publication.

Any info will be greatly appreciated.




.



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Transforming-Incompatible-Stylesheets-over-to-FOP-Apache-tp39504.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

Re: force-page-count="even" dropping data

[Rob Sargent]

Thanks Chris,

I don't think I would make much use of an account.  I do hope the 
example fo is useful, but my client is not likely to pick up the fix 
since we have a work around.


rjs

On 10/21/2013 07:37 AM, Chris Bowditch wrote:

Hi Rob,

As Thanasis mentioned adding an attachment to JIRA is easy enough if 
you have an account. I've uploaded the sample you provided after 
verifying that the last page master is not selected on the latest 
trunk code.


Thanks,

Chris

On 20/10/2013 14:05, Rob Sargent wrote:
I followed the jira link but I did not see a place where I could 
attach this much smaller fo. Please advise or forward.


I did notice that this fo works correctly in FOP 1.0 (ubuntu package) 
placing the table alone on the fourth page, but 
fop1.1rc1(.local-edits) does not.





On 10/11/2013 08:32 AM, Pascal Sancho wrote:

Hi,

This seems to be related to open issue [1].
 From what I read in comments, there is a lake of test file, so your
xsl-fo should help.

[1] https://issues.apache.org/jira/browse/FOP-1976

2013/10/9 Rob Sargent :
Running the attached, admittedly rather large, fo through fop 1.1 
drops the

tabular found beginning at line 135.

Simply changing the force-page-count value on line 61 from "even" to
"no-force" will then generate the tabular data.

I believe it requires at least 3 pages to get into this situation.  A
skeletal one page attempt failed to produce the (un)desired affect. 
I have

not yet tried 5 or greater pages of content.

I suspect it may also require that the fourth page have only the 
tabular

data, but my tests are inconclusive.


I would really appreciate confirmation or contradiction from the 
group.


Thanks

rjs







-
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



-
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: force-page-count="even" dropping data

[Rob Sargent]

I followed the jira link but I did not see a place where I could attach 
this much smaller fo. Please advise or forward.


I did notice that this fo works correctly in FOP 1.0 (ubuntu package) 
placing the table alone on the fourth page, but fop1.1rc1(.local-edits) 
does not.





On 10/11/2013 08:32 AM, Pascal Sancho wrote:

Hi,

This seems to be related to open issue [1].
 From what I read in comments, there is a lake of test file, so your
xsl-fo should help.

[1] https://issues.apache.org/jira/browse/FOP-1976

2013/10/9 Rob Sargent :

Running the attached, admittedly rather large, fo through fop 1.1 drops the
tabular found beginning at line 135.

Simply changing the force-page-count value on line 61 from "even" to
"no-force" will then generate the tabular data.

I believe it requires at least 3 pages to get into this situation.  A
skeletal one page attempt failed to produce the (un)desired affect. I have
not yet tried 5 or greater pages of content.

I suspect it may also require that the fourth page have only the tabular
data, but my tests are inconclusive.


I would really appreciate confirmation or contradiction from the group.

Thanks

rjs







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






http://www.w3.org/1999/XSL/Format"; xmlns:xalan="http://xml.apache.org/xslt"; xmlns:size="xalan://com.amirsys.printing.fop.FopTableSizer" xmlns:ec="xalan://com.amirsys.utilities.ElementConversion">
  

  
  
  


  
  
  
  


  
  
  


  
  
  
  


  
  
  
  


  
  
  


  
  
  


  


  
  
  



  


  


  

  
  

  
 
ADRENAL AND PARAGANGLIA: DIAGNOSIS
  


  
 
ADRENAL AND PARAGANGLIA: DIAGNOSIS
  
  

  




  

  




  

  Criteria for Differentiation Between Adrenal Cortical Adenoma and Carcinoma 

  
  

  Criteria


  Adenoma


  Carcinoma

  
  

  Hormone production


  Often functional


  Usually nonfunctional

  
  

  Gross


  Weight <50 grams


  Weight >100 grams

  
  

  Tumor gross color


  Variable


  Variable; does not differentiate from adenoma

  
  

  Circumscription


  Well circumscribed


  Invasive

  
  

  Hemorrhage


  Absent


  Frequent

  
  

  Necrosis


  Absent


  Frequent

  
  

  Capsular invasion


  Absent
   

Re: force-page-count="even" dropping data

[Rob Sargent]

Chris,

I'll try to make a smaller file this weekend but I have a hunch it only 
happens on odd pages and maybe n > 1.  My second guess is that the flow 
on the missing page is actually empty, the only missing data in the 
example I sent goes in the region-before (of the missing last page).  
Note: as a work around I've changed the page-sequence to NOT use the 
last-page trick.  With that, the tabular data always shows up and page 
caused by "extra content" gets proper flow.  (We write "fixed-length" 
chapters, 1-5 pages, the tabular data is always on last page.)


Have you been able to use the file I sent earlier?

Later,
rjs

On 10/18/2013 02:46 AM, Chris Bowditch wrote:

Hi Rob,

Any sample FO File that demonstrates the issue will do. Obviously a 
shorter file is preferrable but even a long file is better than none 
at all. All we have on the bug report currently is a description of a 
preceived issue from looking at the code. I requested a sample there 
last year, but the reported did not respond.


Thanks,

Chris


On 11/10/2013 16:04, Rob Sargent wrote:

Shall do.

Since fop usage is not longer my day job it will be more difficult to 
contribute much. Not sure how much shorter the fop can be since I 
think it requires more than two pages to trip problem.  Would prose 
content as opposed to bullet content help?


On 10/11/2013 08:56 AM, Pascal Sancho wrote:

Yes,
all comment is welcome.
if you can provide (attach to the issue) a reduced test file, that
should help too.

2013/10/11 Rob Sargent :

Oh, so nice to not be alone! Thanks.

Should I add comment to this thread or to the issue you mention?

rjs





On 10/11/2013 08:32 AM, Pascal Sancho wrote:

Hi,

This seems to be related to open issue [1].
  From what I read in comments, there is a lake of test file, so your
xsl-fo should help.

[1] https://issues.apache.org/jira/browse/FOP-1976

2013/10/9 Rob Sargent :
Running the attached, admittedly rather large, fo through fop 1.1 
drops

the
tabular found beginning at line 135.

Simply changing the force-page-count value on line 61 from "even" to
"no-force" will then generate the tabular data.

I believe it requires at least 3 pages to get into this 
situation.  A
skeletal one page attempt failed to produce the (un)desired 
affect. I

have
not yet tried 5 or greater pages of content.

I suspect it may also require that the fourth page have only the 
tabular

data, but my tests are inconclusive.


I would really appreciate confirmation or contradiction from the 
group.


Thanks

rjs







- 


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







-
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




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

Re: force-page-count="even" dropping data

[Rob Sargent]

Shall do.

Since fop usage is not longer my day job it will be more difficult to 
contribute much. Not sure how much shorter the fop can be since I think 
it requires more than two pages to trip problem.  Would prose content as 
opposed to bullet content help?


On 10/11/2013 08:56 AM, Pascal Sancho wrote:

Yes,
all comment is welcome.
if you can provide (attach to the issue) a reduced test file, that
should help too.

2013/10/11 Rob Sargent :

Oh, so nice to not be alone! Thanks.

Should I add comment to this thread or to the issue you mention?

rjs





On 10/11/2013 08:32 AM, Pascal Sancho wrote:

Hi,

This seems to be related to open issue [1].
  From what I read in comments, there is a lake of test file, so your
xsl-fo should help.

[1] https://issues.apache.org/jira/browse/FOP-1976

2013/10/9 Rob Sargent :

Running the attached, admittedly rather large, fo through fop 1.1 drops
the
tabular found beginning at line 135.

Simply changing the force-page-count value on line 61 from "even" to
"no-force" will then generate the tabular data.

I believe it requires at least 3 pages to get into this situation.  A
skeletal one page attempt failed to produce the (un)desired affect. I
have
not yet tried 5 or greater pages of content.

I suspect it may also require that the fourth page have only the tabular
data, but my tests are inconclusive.


I would really appreciate confirmation or contradiction from the group.

Thanks

rjs







-
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







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

Re: force-page-count="even" dropping data

[Rob Sargent]

Oh, so nice to not be alone! Thanks.

Should I add comment to this thread or to the issue you mention?

rjs




On 10/11/2013 08:32 AM, Pascal Sancho wrote:

Hi,

This seems to be related to open issue [1].
 From what I read in comments, there is a lake of test file, so your
xsl-fo should help.

[1] https://issues.apache.org/jira/browse/FOP-1976

2013/10/9 Rob Sargent :

Running the attached, admittedly rather large, fo through fop 1.1 drops the
tabular found beginning at line 135.

Simply changing the force-page-count value on line 61 from "even" to
"no-force" will then generate the tabular data.

I believe it requires at least 3 pages to get into this situation.  A
skeletal one page attempt failed to produce the (un)desired affect. I have
not yet tried 5 or greater pages of content.

I suspect it may also require that the fourth page have only the tabular
data, but my tests are inconclusive.


I would really appreciate confirmation or contradiction from the group.

Thanks

rjs







-
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: Does fop-1.1 block-container respect "top" attribute?

[Rob Sargent]

Thanks! I misread the compliance list. I'll give those suggestions a shot.

Btw, I never got any suggestion from Glen.  Just the two PSs as you show 
below.


rjs

On 08/28/2013 02:11 AM, Pascal Sancho wrote:

Hi,

top is one of the relative position properties, when applied to the
fo:block (see [1] & [2]).
Currently, FOP doesn't implement such properties (see [2]).

I see 2 workaround alternatives:
As Glenn said, you should use absolute ones that come with fo:block-container:

   ...


Or play with space-before property:

...



[1] http://www.w3.org/TR/xsl/#fo_block
[2] http://www.w3.org/TR/xsl/#common-relative-position-properties
[3] 
http://xmlgraphics.apache.org/fop/compliance.html#fo-property-commonrelpos-section


2013/8/28 Glenn Adams :

P.S. In the future, don't bother sending the XSLT if your question is
related to formatting. Only the XSL-FO content is relevant.

P.S.S. Why do you use nested block containers for the first block?


On Tue, Aug 27, 2013 at 5:24 PM, Rob Sargent  wrote:

I cannot seem to push a block down using 'top="n"' set to any value n > 0
(and < 1 of course)

I've even added an extra, enclosing (superfluous?) block-container inside
the table-cell. "left" and "right" are working just fine but "top" not so
much.

I thought this was a compliant piece of FOP.  Am I wrong about that or
just doing something stupid again. (Hey, I've been away awhile).

Thanks.

My xsl: this template is called as the table-cell is laid out.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 


My fop:
  

   
   
 
   
   


   Anterior surface of
patella


Patellar tendon

   
  Quadriceps tendon
   
  

-
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

Does fop-1.1 block-container respect "top" attribute?

[Rob Sargent]

I cannot seem to push a block down using 'top="n"' set to any value n > 
0 (and < 1 of course)


I've even added an extra, enclosing (superfluous?) block-container 
inside the table-cell. "left" and "right" are working just fine but 
"top" not so much.


I thought this was a compliant piece of FOP.  Am I wrong about that or 
just doing something stupid again. (Hey, I've been away awhile).


Thanks.

My xsl: this template is called as the table-cell is laid out.





















height="{$scoutsize}in" width="{$scoutsize}in">



























select="$curpage/image[@pos= $curpos + $imageCount]" />











My fop:
 
   
  position="absolute" left="0" top="0.1">

  
content-height="1in" content-width="1in" display-align="center" 
src="ref_scout_3_0_650043924" />

  
  
   
   top="3.9297774842857143in" position="absolute" left="0.0in" height="0.6in">
  white-space-collapse="false" font-size="8pt" 
font-family="StoneSerif">Anterior surface of patella

   
   top="5.698118852857143in" position="absolute" left="0.0in" height="0.6in">
   white-space-collapse="false" font-size="8pt" 
font-family="StoneSerif">Patellar tendon

   
  top="2.4832606942857147in" position="absolute" left="0.0in" height="0.6in">
 white-space-collapse="false" font-size="8pt" 
font-family="StoneSerif">Quadriceps tendon

  
 

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

Re: is there a way to output content only in odd pages and leave the even page blank, using Apache FOP?

[Rob Sargent]

Yes it works in fop1.1.  What are you seeing?

See below.

On 03/01/2013 01:10 AM, jeffreyfilter wrote:

Does it work on FOP 1.1 ?

Following is the code sample. What are the modifications to do ?
























remove this?

blank-or-not-blank="not-blank"/>


since your body will be blank and zero











--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/is-there-a-way-to-output-content-only-in-odd-pages-and-leave-the-even-page-blank-using-Apache-FOP-tp38068p38079.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




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

Re: is there a way to output content only in odd pages and leave the even page blank, using Apache FOP?

[Rob Sargent]

Yes.  You can have a zero-lenght region body on the left page 
definition. Place the images in the region-before (or region-after)

On 02/28/2013 02:57 AM, jeffreyfilter wrote:

is there a way to output content only in odd pages and leave the even page
blank, using Apache FOP



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/is-there-a-way-to-output-content-only-in-odd-pages-and-leave-the-even-page-blank-using-Apache-FOP-tp38068.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




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

Re: intermeditate format not behaving on command line

[Rob Sargent]

Alex, thanks for the diagnosis.

Not sure where the space reformat comes but can fix that one way or t'other.

rjs



On 02/22/2013 02:01 PM, Alexios Giotis wrote:

My guess is that during the processing of the AT or during the beautification 
of the XML, you are replacing
 
with


Fixing this and changing the fonts to "Times" gives me the attached pdf.

HTH,
Alex



On 22 Feb 2013, at 22:14, Rob Sargent  wrote:


Well of course.  Silly me.

Now I have the pleasure of tracking down a NumberFormatException.  Is my file 
(attached) not useful standalone?

java.lang.NumberFormatException: null
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:303)
at 
org.apache.fop.cli.AreaTreeInputHandler.renderTo(AreaTreeInputHandler.java:75)
at org.apache.fop.cli.Main.startFOP(Main.java:177)
at org.apache.fop.cli.Main.main(Main.java:208)
Caused by: java.lang.NumberFormatException: null
at java.lang.Integer.parseInt(Integer.java:417)
at java.lang.Integer.parseInt(Integer.java:499)
at 
org.apache.fop.area.AreaTreeParser$Handler.setAreaAttributes(AreaTreeParser.java:1036)
at 
org.apache.fop.area.AreaTreeParser$Handler.access$4000(AreaTreeParser.java:139)
at 
org.apache.fop.area.AreaTreeParser$Handler$SpaceMaker.endElement(AreaTreeParser.java:827)
at 
org.apache.fop.area.AreaTreeParser$Handler.endElement(AreaTreeParser.java:352)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.endElement(TransformerIdentityImpl.java:1101)
at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown 
Source)
at org.apache.xerces.xinclude.XIncludeHandler.emptyElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown 
Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
 Source)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown 
Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at 
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:484)
at org.apache.fop.cli.InputHandler.transformTo(InputHandler.java:300)
... 3 more


On 02/22/2013 01:17 AM, Alexios Giotis wrote:

Hi Rob,

This is the area tree, not the fop intermediate format.

Try using

fop -atin ifin.xml -pdf ifin.pdf

Alex


On 22 Feb 2013, at 02:41, Rob Sargent  wrote:


Unless of course I'm doing something silly (again).

Using fop1.1 I capture the IF from a java program to get the overall page size 
of tables. I then use that to size the region-before.

For debuging I write the IF to a file and it looks like this



   
 
   
 
   
 
 
   

Is that format correct for the fop bash script which comes with the source code?

With a local classpath I can run
fop -xml f.xml -xsl f.xsl -pdf f.pdf
Trying to print just the tables from the IF file like this
fop -ifin ifin.xml -pdf ifin.pdf
generates a zero-length ifin.pdf.

Turning on --execdebug doesn't give me any insights.  It simply show the exec'd 
command.







-
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




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

intermeditate format not behaving on command line

[Rob Sargent]

Unless of course I'm doing something silly (again).

Using fop1.1I capture the IF from a java program to get the overall page 
size of tables. I then use that to size the region-before.


For debuging I write the IF to a file and it looks like this

   
   
  

  

  


  


Is that format correct for the fop bash script which comes with the 
source code?


With a local classpath I can run

   fop -xml f.xml -xsl f.xsl -pdf f.pdf

Trying to print just the tables from the IF file like this

   fop -ifin ifin.xml -pdf ifin.pdf

generates a zero-length ifin.pdf.

Turning on --execdebug doesn't give me any insights. It simply show the 
exec'd command.

Re: FOP 1.1 - Use Transparent image as Non-Transparent

[Rob Sargent]

Put it on top of a white background using the z-axis.

On 02/13/2013 12:30 PM, Luis Bernardo wrote:


I am not familiar with that feature but I would expect that if your 
image is GIF and the feature is for PNG then it will not work. Why not 
convert the image to one without transparency outside FOP? If FOP 
0.20.5 was not not handling transparency it is probably because it had 
not been implemented.


On 2/13/13 6:25 AM, Neeraj wrote:

Hi,

I am using FOP 1.1, Command line to generate PDF file.

I am having a transparent GIF image and want FOP to treat it as non
transparent image (Just like FOP 0.20.5). Is there any setting in FOP
configuration file which can  provide this functionality?

I already tried following settings for PNG transparent images, but it
is not working.


false


Any suggestions will be appreciated.

Thanks
Neeraj

-
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




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

Re: How get fixed width for inline FO ?

[Rob Sargent]

On 02/09/2013 04:31 PM, Rob Sargent wrote:

Note that there needs to be a bounding fo:list-block on this.  I'm 
actually in nested lists and didn't want to show the entire template.  
Sorry if this confused anyone.
Leaders work just fine.  Correct page number for content works too if 
you id the start block of each entry in you table of contents.  Below 
each "dx-element" contains an attribute "ref-id" which 
fo:page-number-citation uses to deduce the page on which each 
particular item.





line-height="1.0">  


start-indent="body-start()">
font-weight="normal" text-align-last="justify" margin-right="10pt">
 





 







If you don't want the list of tables to expand to the full width of 
your region-body, you need a fixed-width bounding block (likely with 
overflow="hidden")


On 02/09/2013 04:08 PM, Terence M. Bandoian wrote:

On 2/1/2013 1:44 PM, Steve Fogel wrote:

Hi...

Thanks for the reply.

Would the list approach you suggest work if I want to have a title, 
then a leader () then a page # in the list body?


Wondering if there isn't a simpler way to just specify a minimum 
width for an inline area. Below is an example of what I want to 
output as a list of tables.


2-7   createTable Parameters ... 2-61
2-8   createView Parameters  2-62
2-9   createSynonym Parameters . 2-63
2-10  createProc Parameters  2-64
2-11  createPackage Parameters.. 2-65

You can see that the table number at the left can have a varying 
width, but the area needs to be fixed width so the table names are 
all left-aligned. FOP 1.1 seems to ignore the width property for the 
 element.


Thx

Steve




Steve Fogel | Information Architect, Oracle Database | 650.506.4914
Oracle Server Technologies Information Development
500 Oracle Parkway | M/S 4op1126 | Redwood Shores, CA 94065


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
Sent: Friday, February 01, 2013 3:41 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: How get fixed width for inline FO ?

On 2/1/2013 2:37 AM, Steve Fogel wrote:

Hi, all..

I'd like to specify a fixed width for an inline FO with FOP 1.1. 
It's in a List of Tables in the front matter of a book. For each 
table in the list, table number area should be fixed width followed 
by table title.


I tried this (simplified):



inline-progression-dimension="6em">4-5Summary of Commands




I also tried using just the width property instead of 
inline-progression-dimension.


Neither worked. Can someone help?

Thx

Steve


Hi, Steve-

I don't remember all the details but I did something like this when 
I needed fixed horizontal widths in the footer of a document:





  



 
 





Hope it helps.

-Terence Bandoian



Hi, Steve-

Sorry I took so long to respond.  Have you looked at:

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

One of the examples included with FOP is leader.fo which "shows 
different uses of fo:leader, p.e. as rule or in table of 
content(s)".  I haven't looked at the example and don't know if it 
works but, based on the description, it seems to be along the lines 
of what you're looking for.  You may have to get creative to get 
exactly what you want.


Hope this helps.

-Terence Bandoian


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

Re: How get fixed width for inline FO ?

[Rob Sargent]

Leaders work just fine.  Correct page number for content works too if 
you id the start block of each entry in you table of contents.  Below 
each "dx-element" contains an attribute "ref-id" which 
fo:page-number-citation uses to deduce the page on which each particular 
item.





line-height="1.0">  



font-weight="normal" text-align-last="justify" margin-right="10pt">
 





 







If you don't want the list of tables to expand to the full width of your 
region-body, you need a fixed-width bounding block (likely with 
overflow="hidden")


On 02/09/2013 04:08 PM, Terence M. Bandoian wrote:

On 2/1/2013 1:44 PM, Steve Fogel wrote:

Hi...

Thanks for the reply.

Would the list approach you suggest work if I want to have a title, 
then a leader () then a page # in the list body?


Wondering if there isn't a simpler way to just specify a minimum 
width for an inline area. Below is an example of what I want to 
output as a list of tables.


2-7   createTable Parameters ... 2-61
2-8   createView Parameters  2-62
2-9   createSynonym Parameters . 2-63
2-10  createProc Parameters  2-64
2-11  createPackage Parameters.. 2-65

You can see that the table number at the left can have a varying 
width, but the area needs to be fixed width so the table names are 
all left-aligned. FOP 1.1 seems to ignore the width property for the 
 element.


Thx

Steve




Steve Fogel | Information Architect, Oracle Database | 650.506.4914
Oracle Server Technologies Information Development
500 Oracle Parkway | M/S 4op1126 | Redwood Shores, CA 94065


-Original Message-
From: Terence M. Bandoian [mailto:tere...@tmbsw.com]
Sent: Friday, February 01, 2013 3:41 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: How get fixed width for inline FO ?

On 2/1/2013 2:37 AM, Steve Fogel wrote:

Hi, all..

I'd like to specify a fixed width for an inline FO with FOP 1.1. 
It's in a List of Tables in the front matter of a book. For each 
table in the list, table number area should be fixed width followed 
by table title.


I tried this (simplified):



inline-progression-dimension="6em">4-5Summary of Commands




I also tried using just the width property instead of 
inline-progression-dimension.


Neither worked. Can someone help?

Thx

Steve


Hi, Steve-

I don't remember all the details but I did something like this when I 
needed fixed horizontal widths in the footer of a document:





  



  






Hope it helps.

-Terence Bandoian



Hi, Steve-

Sorry I took so long to respond.  Have you looked at:

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

One of the examples included with FOP is leader.fo which "shows 
different uses of fo:leader, p.e. as rule or in table of content(s)".  
I haven't looked at the example and don't know if it works but, based 
on the description, it seems to be along the lines of what you're 
looking for.  You may have to get creative to get exactly what you want.


Hope this helps.

-Terence Bandoian


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

Re: How get fixed width for inline FO ?

[Rob Sargent]

On 02/01/2013 08:56 PM, Rob Sargent wrote:


No sure why the width isn't set on the containing block, with a two 
column table for the data presented


Or a column definition for the entire page master if that's more 
appropriate.


You might be able to do this with just a list if you can set the label 
to be your first datum but the width will definitely have to come from 
the containing block.


keep-with-next="{$keeper}">

  
font-weight="normal" font-style="normal">
  


  
   






 







On 02/01/2013 08:06 PM, Manuel Mall wrote:

FOP 1.1 seems to ignore the width property for the 

element.

The width property doesn't apply to fo:inline elements it only applies
to block level elements that is formatting elements that essentially
generate a rectangular area. An  can begin in the middle of a
line and end a few lines further down in a completely different position
within that line. It is not rectangular in shape and from the
specification point of view it is not a block level element.

I know this doesn't help you solve your problem just trying to explain
why your current approach doesn't work.

Cheers

Manuel


-
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




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

Re: How get fixed width for inline FO ?

[Rob Sargent]

No sure why the width isn't set on the containing block, with a two 
column table for the data presented


Or a column definition for the entire page master if that's more 
appropriate.


You might be able to do this with just a list if you can set the label 
to be your first datum but the width will definitely have to come from 
the containing block.


keep-with-next="{$keeper}">

  
font-weight="normal" font-style="normal">
  


  
   



On 02/01/2013 08:06 PM, Manuel Mall wrote:

FOP 1.1 seems to ignore the width property for the 

element.

The width property doesn't apply to fo:inline elements it only applies
to block level elements that is formatting elements that essentially
generate a rectangular area. An  can begin in the middle of a
line and end a few lines further down in a completely different position
within that line. It is not rectangular in shape and from the
specification point of view it is not a block level element.

I know this doesn't help you solve your problem just trying to explain
why your current approach doesn't work.

Cheers

Manuel
  



-
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: text on even pages, images on odd pages

[Rob Sargent]

Sounds like you may be in luck.  If "content about a subject" can define 
on flow you should be able to put tease the images into static regions 
on right-page.


On 11/13/2012 06:28 AM, Bonekrusher wrote:

Thanks,

I'll give your suggestion a try. My xml comes in as fragments, so images can
be associated with the text. In my case, A fragment defines a block of
content about a subject.



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/text-on-odd-pages-images-on-even-pages-tp37330p37354.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




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

Re: text on even pages, images on odd pages

[Rob Sargent]

You can dynamically size the region-body and region-before of the 
right-page master if you have any information on page layout from the 
incoming xml - ie. if it's known or knowable that the upcoming 
right-page has a single image with text.  This can be accomplished if 
the app capturing the printable information also collects information 
about image count (how much of the page is required) and placement.


What does your incoming data look like?



On 11/11/2012 08:56 AM, Bonekrusher wrote:

Thanks. This is a good approach except I could have text only which would
render on both odd and even.  Perhaps I could use markers defined on the odd
pages for the images, but this might be an issue if more than one image is
found on a page...

I'll work on it.



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/text-on-odd-pages-images-on-even-pages-tp37330p37332.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






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

Re: text on even pages, images on odd pages

[Rob Sargent]

This is entirely do-able.

Define two page masters. left-master has normal region-body and will get 
all the text. right-master will have zero-length region-body and 
region-before consumes entire page length.  All your images go into 
static-content. You may want a first-page master for special things on 
each section of the manual.


make a repeating page layout sequence of left-master, right-master, 
using even/odd as needed.


Expect to have fun with text which doesn't have matching images; text 
only on the last page;



On 11/11/2012 06:16 AM, Bonekrusher wrote:

Hi,

I have an odd requirement for outputting text and images for a "pocket size
book" (4in x 5.5in). The requirement states:

"Place text for pocket-sized manuals on the right-hand pages with supporting
illustration on the
facing left-hand pages"

Is this possible with xsl-fo, that is, to request a figure be rendered on an
even page only or do I need to manipulated the xml->xsl->fo to rearrange the
text images into alternating page sequences?

After some though, I think this is almost an impossible requirement to
handle by xslt/xsl-fo programing.

Any suggestions or ideas?



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/text-on-even-pages-images-on-odd-pages-tp37330.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




-
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

[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 <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
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

[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 <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
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

[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 <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).









http://www.w3.org/1999/XSL/Format"; xmlns:xalan="http://xml.apache.org/xslt"; xmlns:ec="xalan://com.amirsys.utilities.ElementConversion">
  

  


  


  
  


  
  

  
  

  



  

  

  


  

  
  

   

  
  

   

  
  

   

  
  

  

  

  

  


  
  

  





-
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

[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 <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

[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 <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?

[Rob Sargent]

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).


On 11/05/2012 04:32 PM, Rob Sargent wrote:

Thank you Luis

I may have to embed a table within a table as you suggest. Or perhaps 
I can play with "layers" and z-values.  Any other hints appreciated.


rjs

On 11/05/2012 04:09 PM, Luis Bernardo wrote:


I assume you refer to the sidebar.fo sample.

As you said, the lines are not visible in Adobe. They are visible in 
Mac's own Preview though. I looked at the *.fo and although I don't 
understand what you are trying to achieve I do see that the output in 
Preview is not what I would expect. Can you provide a smaller 
example? Meanwhile, if you have a problem in hands with unexpected 
lines due to the use of row or column spans try to get  around it by 
nesting tables.


On 11/5/12 7:41 PM, Rob Sargent wrote:


Correction:  the referenced previous post did include an fo of the 
table in question.


rjs

On 11/05/2012 12:38 PM, Rob Sargent wrote:


Glenn,

My apologies for not including relevant fo etc but the original 
post I referenced didn't need them, explained the situation well 
enough for at least one available savant and I am only asking if 
there is (another) silent change in the pdf output irrespective of 
any fo input.  (The other silent change being the in-stream 
description of rgb colors.)


rjs

On 11/05/2012 10:58 AM, Glenn Adams wrote:
Rob, I'm sure you realize nobody can respond to such a query 
unless they can read your mind to learn the input you used and the 
output you are seeing. Since such skills are hard to come by, I'd 
suggest you *always* provide sample input and output files when 
asking such a question. We devs are very few in number and you 
absolutely *must* do everything possible to help us determine the 
source of a problem. There is a well defined process here: submit 
a bug report with a reduced (maximally minimal) input file and an 
output file. Absent this, don't expect any response.


G.

On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:


In January 2011, I asked about the spurious lines between rows
of tables (here

<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the lines are
showing up on the pages from the print shop, but not our not
local (low-res) printers.  Is this another silent change in
fop-1.1 pdf generataion?

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

[Rob Sargent]

Thank you Luis

I may have to embed a table within a table as you suggest. Or perhaps I 
can play with "layers" and z-values.  Any other hints appreciated.


rjs

On 11/05/2012 04:09 PM, Luis Bernardo wrote:


I assume you refer to the sidebar.fo sample.

As you said, the lines are not visible in Adobe. They are visible in 
Mac's own Preview though. I looked at the *.fo and although I don't 
understand what you are trying to achieve I do see that the output in 
Preview is not what I would expect. Can you provide a smaller example? 
Meanwhile, if you have a problem in hands with unexpected lines due to 
the use of row or column spans try to get  around it by nesting tables.


On 11/5/12 7:41 PM, Rob Sargent wrote:


Correction:  the referenced previous post did include an fo of the 
table in question.


rjs

On 11/05/2012 12:38 PM, Rob Sargent wrote:


Glenn,

My apologies for not including relevant fo etc but the original post 
I referenced didn't need them, explained the situation well enough 
for at least one available savant and I am only asking if there is 
(another) silent change in the pdf output irrespective of any fo 
input.  (The other silent change being the in-stream description of 
rgb colors.)


rjs

On 11/05/2012 10:58 AM, Glenn Adams wrote:
Rob, I'm sure you realize nobody can respond to such a query unless 
they can read your mind to learn the input you used and the output 
you are seeing. Since such skills are hard to come by, I'd suggest 
you *always* provide sample input and output files when asking such 
a question. We devs are very few in number and you absolutely 
*must* do everything possible to help us determine the source of a 
problem. There is a well defined process here: submit a bug report 
with a reduced (maximally minimal) input file and an output file. 
Absent this, don't expect any response.


G.

On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:


In January 2011, I asked about the spurious lines between rows
of tables (here

<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the lines are
showing up on the pages from the print shop, but not our not
local (low-res) printers.  Is this another silent change in
fop-1.1 pdf generataion?

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

[Rob Sargent]

As you saw in the referenced original thread, the problem was in the 
viewer (Evince in particular). Now it appears that some (only the outter 
edge) of the spurious lines have made it to the printed page, where as 
before the did not. There is an fo producing the table in question 
however our ultimate produce gets additional bleed colouration prior to 
production printing.  I'm just hoping this rings a bell for another 
user, or someone familiar with the end game of printing from pdf.


rjs

On 11/05/2012 03:15 PM, Glenn Adams wrote:
As you point out, this is a problem you saw with 1.0 and now see with 
1.1, so it isn't a first communique. In any case, I'd rather have a 
bug report with test input/output files to evaluate. It's easier to 
close a non-bug than to evaluate a query that is absent the necessary 
data to properly evaluate it.


Clearly, strict usage questions should come to this list first, but 
you aren't asking a usage question.


On Tue, Nov 6, 2012 at 6:10 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:


I have no intention of circumventing normal processes, though I'm
surprised that your recommended first communique is to submit a
bug rather than pose a question. Is this the general consensus?

I don't know if there is a bug - there wasn't a year ago.  Some
behaviour seems to have changed since Feb. 2011 - it could be the
print-shop.  I'm just asking if anyone on the list, including but
not limited to the developers, has any insight into the matter.

rjs




On 11/05/2012 01:34 PM, Glenn Adams wrote:

file a bug and attach the files if you wish a dev to evaluate;
personally, i ignore requests on fop-users that attempt to
circumvent the normal bug reporting process

On Tue, Nov 6, 2012 at 3:41 AM, Rob Sargent
mailto:rsarg...@xmission.com>> wrote:


Correction:  the referenced previous post did include an fo
of the table in question.

rjs


On 11/05/2012 12:38 PM, Rob Sargent wrote:


Glenn,

My apologies for not including relevant fo etc but the
original post I referenced didn't need them, explained the
situation well enough for at least one available savant and
I am only asking if there is (another) silent change in the
pdf output irrespective of any fo input.  (The other silent
change being the in-stream description of rgb colors.)

rjs

On 11/05/2012 10:58 AM, Glenn Adams wrote:

Rob, I'm sure you realize nobody can respond to such a
query unless they can read your mind to learn the input you
used and the output you are seeing. Since such skills are
hard to come by, I'd suggest you *always* provide sample
input and output files when asking such a question. We devs
are very few in number and you absolutely *must* do
everything possible to help us determine the source of a
problem. There is a well defined process here: submit a bug
report with a reduced (maximally minimal) input file and an
output file. Absent this, don't expect any response.

G.

On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent
mailto:rsarg...@xmission.com>> wrote:

In January 2011, I asked about the spurious lines
between rows of tables (here

<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the
lines are showing up on the pages from the print shop,
but not our not local (low-res) printers.  Is this
another silent change in fop-1.1 pdf generataion?

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

[Rob Sargent]

I have no intention of circumventing normal processes, though I'm 
surprised that your recommended first communique is to submit a bug 
rather than pose a question. Is this the general consensus?


I don't know if there is a bug - there wasn't a year ago.  Some 
behaviour seems to have changed since Feb. 2011 - it could be the 
print-shop.  I'm just asking if anyone on the list, including but not 
limited to the developers, has any insight into the matter.


rjs



On 11/05/2012 01:34 PM, Glenn Adams wrote:
file a bug and attach the files if you wish a dev to evaluate; 
personally, i ignore requests on fop-users that attempt to circumvent 
the normal bug reporting process


On Tue, Nov 6, 2012 at 3:41 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:



Correction:  the referenced previous post did include an fo of the
table in question.

rjs


    On 11/05/2012 12:38 PM, Rob Sargent wrote:


Glenn,

My apologies for not including relevant fo etc but the original
post I referenced didn't need them, explained the situation well
enough for at least one available savant and I am only asking if
there is (another) silent change in the pdf output irrespective
of any fo input.  (The other silent change being the in-stream
description of rgb colors.)

rjs

On 11/05/2012 10:58 AM, Glenn Adams wrote:

Rob, I'm sure you realize nobody can respond to such a query
unless they can read your mind to learn the input you used and
the output you are seeing. Since such skills are hard to come
by, I'd suggest you *always* provide sample input and output
files when asking such a question. We devs are very few in
number and you absolutely *must* do everything possible to help
us determine the source of a problem. There is a well defined
process here: submit a bug report with a reduced (maximally
minimal) input file and an output file. Absent this, don't
expect any response.

G.

On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent
mailto:rsarg...@xmission.com>> wrote:

In January 2011, I asked about the spurious lines between
rows of tables (here

<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the lines
are showing up on the pages from the print shop, but not our
not local (low-res) printers.  Is this another silent change
in fop-1.1 pdf generataion?

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

[Rob Sargent]

Correction:  the referenced previous post did include an fo of the table 
in question.


rjs

On 11/05/2012 12:38 PM, Rob Sargent wrote:


Glenn,

My apologies for not including relevant fo etc but the original post I 
referenced didn't need them, explained the situation well enough for 
at least one available savant and I am only asking if there is 
(another) silent change in the pdf output irrespective of any fo 
input.  (The other silent change being the in-stream description of 
rgb colors.)


rjs

On 11/05/2012 10:58 AM, Glenn Adams wrote:
Rob, I'm sure you realize nobody can respond to such a query unless 
they can read your mind to learn the input you used and the output 
you are seeing. Since such skills are hard to come by, I'd suggest 
you *always* provide sample input and output files when asking such a 
question. We devs are very few in number and you absolutely *must* do 
everything possible to help us determine the source of a problem. 
There is a well defined process here: submit a bug report with a 
reduced (maximally minimal) input file and an output file. Absent 
this, don't expect any response.


G.

On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:


In January 2011, I asked about the spurious lines between rows of
tables (here

<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the lines are
showing up on the pages from the print shop, but not our not
local (low-res) printers.  Is this another silent change in
fop-1.1 pdf generataion?

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

[Rob Sargent]

Glenn,

My apologies for not including relevant fo etc but the original post I 
referenced didn't need them, explained the situation well enough for at 
least one available savant and I am only asking if there is (another) 
silent change in the pdf output irrespective of any fo input.  (The 
other silent change being the in-stream description of rgb colors.)


rjs

On 11/05/2012 10:58 AM, Glenn Adams wrote:
Rob, I'm sure you realize nobody can respond to such a query unless 
they can read your mind to learn the input you used and the output you 
are seeing. Since such skills are hard to come by, I'd suggest you 
*always* provide sample input and output files when asking such a 
question. We devs are very few in number and you absolutely *must* do 
everything possible to help us determine the source of a problem. 
There is a well defined process here: submit a bug report with a 
reduced (maximally minimal) input file and an output file. Absent 
this, don't expect any response.


G.

On Tue, Nov 6, 2012 at 1:28 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:


In January 2011, I asked about the spurious lines between rows of
tables (here

<http://apache-fop.1065347.n5.nabble.com/Can-t-get-rid-of-line-between-rows-tt12480.html>)
and that was all on fop-1.0. Now on fop-1.1 and the lines are
showing up on the pages from the print shop, but not our not local
(low-res) printers.  Is this another silent change in fop-1.1 pdf
generataion?

Re: FO:list label being overprinted with list body

[Rob Sargent]

Here's the nub of how we're doing it. This is in a template which is 
handed the values for keeper, bullet-char and I show a trimmed version 
of the bullet-text macro. (Choose your own font of course, or let it be 
inherited.)


   keep-with-next="{$keeper}">

  
font-weight="normal" font-style="normal">

  

  
  











On 10/12/2012 09:11 AM, stan69 wrote:

Hi, I am trying to create a bulleted list like this:
   
 
   
 
   
 *
   
   
 
   
 
   
 
   

...but in the resulting PDF the * is overprinted with the body text.  Can
you tell me what I'm doing wrong?
Thanks, Stan



--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/FO-list-label-being-overprinted-with-list-body-tp37032.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




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

Re: rgb-cc() in region definitions

[Rob Sargent]

For closure, here 
<https://issues.apache.org/bugzilla/show_bug.cgi?id=53901> is the bug.


On 09/19/2012 03:44 AM, Rob Sargent wrote:


Interesting!

The location of the fo:declaration is quite restricted: Must be after 
layout-master-set (and before page-sequence elements) so that would 
preclude setting background on any region.


We're examining the output from cmyk() now and hopefully we don't run 
into difficulties because of the various icc's used.  Can anyone 
comment on that?


Thanks!

rjs




On 09/19/2012 01:24 AM, Pascal Sancho wrote:

Hi Rob,

sorry for the delay.

In your test case, ICC profiles are not taken into account in the
fo:layout-master-set (probably because fo:declarations comes after),
while in fo:page-sequence all works as expected.
So you may file in a bug entry.
Note that FOP behaves as this whatever the version is (tried against
0.95, 1.0, 1.1rc1 and trunk).

2012/9/18 Rob Sargent :
For what it's worth, I switched from rgb-icc() to cymk() and that 
appears to
work.  I'm not that worried about the non-portability of our fo 
files, but
we do have two colour profiles and I'm not sure whether or not the 
change in

functions would impact our final product.


On 09/18/2012 09:55 AM, Rob Sargent wrote:

Anyone have an opinion on this? Bug v. Not bug? Hoping against hope 
that

I've made some other mistake.

rjs


On 09/14/2012 11:24 AM, Rob Sargent wrote:

This is just a bug, I'm sure. happy to file a bug if this is really the
case.


fop-yellow.xml show nice bright yellow for the background of the 
regions.

fop.xml goes black.

Help!!

On 09/10/2012 12:41 PM, Rob Sargent wrote:

Sorry, forgot the details.: using fop-1.1rc1

On 09/10/2012 12:34 PM, Rob Sargent wrote:

Should I expect rgb-icc(r,g,b,profile,c,y,m,k) to result in the correct
colour in pdf?  I'm getting black. Or do I have to layout each 
region with
an over-arching block with background-color set? Other explicit 
blocks using

rfb-icc() are working correctly on subsequent pages.

Here's the definition of the regions of the firstpage (which is 
coming out

black).

 
   background-color="rgb-icc(1.000, 0.902, 0.753, USWebCoatedSWOP.icc, 
0.000,

0.100, 0.250, 0.000)" margin-left="0.75in" column-gap="0.25in"
margin-bottom="0.6in" column-count="2" margin-top="0.65in" />
   background-color="rgb-icc(1.000,

0.902, 0.753, USWebCoatedSWOP.icc, 0.000, 0.100, 0.250, 0.000)"
extent="0.65in" region-name="header-first" />
   
   background-color="rgb-icc(1.000,

0.902, 0.753, USWebCoatedSWOP.icc, 0.000, 0.100, 0.250, 0.000)"
extent="0.75in" region-name="sidebar-first" />
   background-color="rgb-icc(1.000,

0.902, 0.753, USWebCoatedSWOP.icc, 0.000, 0.100, 0.250, 0.000)"
extent="0.833in" region-name="gutter" />
 

and the declaration of the icc are available

   
 src="jar:file:///d3/arcane/forty/eclipse/plugins/com.amirsys.console_4.9.0/lib/book-printing-core.jar!/USWebCoatedSWOP.icc" 


color-profile-name="USWebCoatedSWOP.icc" />
 src="jar:file:///d3/arcane/forty/eclipse/plugins/com.amirsys.console_4.9.0/lib/book-printing-core.jar!/grayColorDoplar.icc" 


color-profile-name="grayColorDoplar.icc" />
   

And the explicit paths are correct.

We're looking for a peachy backdrop!







-
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: rgb-cc() in region definitions

[Rob Sargent]

Interesting!

The location of the fo:declaration is quite restricted: Must be after 
layout-master-set (and before page-sequence elements) so that would 
preclude setting background on any region.


We're examining the output from cmyk() now and hopefully we don't run 
into difficulties because of the various icc's used.  Can anyone comment 
on that?


Thanks!

rjs




On 09/19/2012 01:24 AM, Pascal Sancho wrote:

Hi Rob,

sorry for the delay.

In your test case, ICC profiles are not taken into account in the
fo:layout-master-set (probably because fo:declarations comes after),
while in fo:page-sequence all works as expected.
So you may file in a bug entry.
Note that FOP behaves as this whatever the version is (tried against
0.95, 1.0, 1.1rc1 and trunk).

2012/9/18 Rob Sargent :

For what it's worth, I switched from rgb-icc() to cymk() and that appears to
work.  I'm not that worried about the non-portability of our fo files, but
we do have two colour profiles and I'm not sure whether or not the change in
functions would impact our final product.


On 09/18/2012 09:55 AM, Rob Sargent wrote:

Anyone have an opinion on this? Bug v. Not bug? Hoping against hope that
I've made some other mistake.

rjs


On 09/14/2012 11:24 AM, Rob Sargent wrote:

This is just a bug, I'm sure. happy to file a bug if this is really the
case.


fop-yellow.xml show nice bright yellow for the background of the regions.
fop.xml goes black.

Help!!

On 09/10/2012 12:41 PM, Rob Sargent wrote:

Sorry, forgot the details.: using fop-1.1rc1

On 09/10/2012 12:34 PM, Rob Sargent wrote:

Should I expect rgb-icc(r,g,b,profile,c,y,m,k) to result in the correct
colour in pdf?  I'm getting black. Or do I have to layout each region with
an over-arching block with background-color set? Other explicit blocks using
rfb-icc() are working correctly on subsequent pages.

Here's the definition of the regions of the firstpage (which is coming out
black).

 
   
   
   
   
   
 

and the declaration of the icc are available

   
 
 
   

And the explicit paths are correct.

We're looking for a peachy backdrop!







-
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: rgb-cc() in region definitions

[Rob Sargent]

For what it's worth, I switched from rgb-icc() to cymk() and that 
appears to work.  I'm not that worried about the non-portability of our 
fo files, but we do have two colour profiles and I'm not sure whether or 
not the change in functions would impact our final product.


On 09/18/2012 09:55 AM, Rob Sargent wrote:
Anyone have an opinion on this? Bug v. Not bug? Hoping against hope 
that I've made some other mistake.


rjs


On 09/14/2012 11:24 AM, Rob Sargent wrote:
This is just a bug, I'm sure.happy to file a bug if this is really 
the case.



fop-yellow.xml show nice bright yellow for the background of the regions.
fop.xml goes black.

Help!!

On 09/10/2012 12:41 PM, Rob Sargent wrote:

Sorry, forgot the details.: using fop-1.1rc1

On 09/10/2012 12:34 PM, Rob Sargent wrote:
Should I expect rgb-icc(r,g,b,profile,c,y,m,k) to result in the 
correct colour in pdf?  I'm getting black. Or do I have to layout 
each region with an over-arching block with background-color set? 
Other explicit blocks using rfb-icc() are working correctly on 
subsequent pages.


Here's the definition of the regions of the firstpage (which is 
coming out black).



  
  
  
  
  


and the declaration of the icc are available

  


  

And the explicit paths are correct.

We're looking for a peachy backdrop!









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

Re: rgb-cc() in region definitions

[Rob Sargent]

Anyone have an opinion on this? Bug v. Not bug? Hoping against hope that 
I've made some other mistake.


rjs


On 09/14/2012 11:24 AM, Rob Sargent wrote:
This is just a bug, I'm sure.happy to file a bug if this is really the 
case.



fop-yellow.xml show nice bright yellow for the background of the regions.
fop.xml goes black.

Help!!

On 09/10/2012 12:41 PM, Rob Sargent wrote:

Sorry, forgot the details.: using fop-1.1rc1

On 09/10/2012 12:34 PM, Rob Sargent wrote:
Should I expect rgb-icc(r,g,b,profile,c,y,m,k) to result in the 
correct colour in pdf?  I'm getting black. Or do I have to layout 
each region with an over-arching block with background-color set? 
Other explicit blocks using rfb-icc() are working correctly on 
subsequent pages.


Here's the definition of the regions of the firstpage (which is 
coming out black).



  
  
  
  
  


and the declaration of the icc are available

  


  

And the explicit paths are correct.

We're looking for a peachy backdrop!









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

Re: rgb-cc() in region definitions

[Rob Sargent]

Sorry, forgot the details.: using fop-1.1rc1

On 09/10/2012 12:34 PM, Rob Sargent wrote:
Should I expect rgb-icc(r,g,b,profile,c,y,m,k) to result in the 
correct colour in pdf?  I'm getting black. Or do I have to layout each 
region with an over-arching block with background-color set? Other 
explicit blocks using rfb-icc() are working correctly on subsequent pages.


Here's the definition of the regions of the firstpage (which is coming 
out black).



  
  
  
  
  


and the declaration of the icc are available

  


  

And the explicit paths are correct.

We're looking for a peachy backdrop!

rgb-cc() in region definitions

[Rob Sargent]

Should I expect rgb-icc(r,g,b,profile,c,y,m,k) to result in the correct 
colour in pdf?  I'm getting black. Or do I have to layout each region 
with an over-arching block with background-color set? Other explicit 
blocks using rfb-icc() are working correctly on subsequent pages.


Here's the definition of the regions of the firstpage (which is coming 
out black).



  
  
  
  
  


and the declaration of the icc are available

  


  

And the explicit paths are correct.

We're looking for a peachy backdrop!

Re: spurious indentation with (small) text lose SOLVED

[Rob Sargent]

On 09/06/2012 12:03 PM, Samuel Penn wrote:
The general layout of the documents themselves isn't particulary 
exciting. There's a lot I'd like to be able to do, especially around 
image and table layout (auto-placement of images, and stretching them 
across two text columns etc), which doesn't yet seem to be possible in 
FOP. 
span="all" doesn't work? You would of course have to split the page into 
before, body and after regions and place some of the content in the 
erstwhile head and footer. Alternatively a trick VH showed me is to 
print content twice covering 200% of the available width and use 
left/right indent at 0% and -100% alternately.  This is how I print 
tables across two pages.


   

There's an example document here: 
http://yags.glendale.org.uk/download/yags-character.pdf Which is built 
from the source XML files here: 
http://yagsbook.svn.sourceforge.net/viewvc/yagsbook/trunk/sources/yags/ 

Re: spurious indentation with (small) text lose SOLVED

[Rob Sargent]

On 09/06/2012 06:04 AM, Samuel Penn wrote:
On Tue, 04 Sep 2012 09:46:23 -0600, Rob Sargent 
 wrote:

 I have long suspected that what we're asking FOP to do is somewhat
"out there".  Man would I love a review of my xsl/fo
transformation.  2700+ lines of xsl can't be a good thing!


That doesn't seem that bad. My own XSLT for FOP is pushing 7000 lines. 
:-)



That's just wrong! :)  What on earth are you doing?

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

Re: spurious indentation with (small) text lose SOLVED

[Rob Sargent]

I hate to wimp-out on you good sir, but I'm /really/ under the gun right 
now.  It will be at least a week before I can (attempt to) put together 
an example fo.


I have long suspected that what we're asking FOP to do is somewhat "out 
there".  Man would I love a review of my xsl/fo transformation.  2700+ 
lines of xsl can't be a good thing!


But it's shaping up to be a beautiful book, thanks to FOP.




On 09/04/2012 09:21 AM, Vincent Hennebert wrote:

On 04/09/12 16:04, Rob Sargent wrote:

Wonderful.  Thank you very much. It's working great here.

An interesting twist on the other side of this thread (re:
MAX_RECOVERY_ATTEMPTS).  We find that if the last image-bearing page of a
chapter is a text-less gallery page the page immediately following page is
confused about it's column-count.  It's defined as a two-column page but the
first column appears to be rendered full width and the second column
over-prints.  I've fixed that by using column-count="2" on the gallery page
and that seems to clear things up.

Could you start a new thread about this and upload a small file showing
the issue?



Thanks again for all you help.  We believe we are good to go to print very
soon.  And just in time! We probably won't wait for the general release of
fop-1.1.

Glad it works. I must say, your documents are pushing FOP to the limit
of its comfort zone...



Cheers,

rjs


Thanks,
Vincent



On 09/04/2012 08:36 AM, Vincent Hennebert wrote:

I’ve just submitted a fix to trunk:
http://svn.apache.org/viewvc?rev=1380667&view=rev

Vincent


On 30/08/12 20:54, rsargent wrote:

Ok if Vincent agrees this is a bug I can make the issue and supply the test
fo.  The patch is his and I don't think I should claim it.


Glenn Adams-2 wrote

First, someone needs to open a bug and submit a patch against the bug.




--
View this message in context:
http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.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


-
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


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

Re: spurious indentation with (small) text lose SOLVED

[Rob Sargent]

Wonderful.  Thank you very much. It's working great here.

An interesting twist on the other side of this thread (re: 
MAX_RECOVERY_ATTEMPTS).  We find that if the last image-bearing page of 
a chapter is a text-less gallery page the page immediately following 
page is confused about it's column-count.  It's defined as a two-column 
page but the first column appears to be rendered full width and the 
second column over-prints.  I've fixed that by using column-count="2" on 
the gallery page and that seems to clear things up.


Thanks again for all you help.  We believe we are good to go to print 
very soon.  And just in time! We probably won't wait for the general 
release of fop-1.1.


Cheers,

rjs

On 09/04/2012 08:36 AM, Vincent Hennebert wrote:

I’ve just submitted a fix to trunk:
http://svn.apache.org/viewvc?rev=1380667&view=rev

Vincent


On 30/08/12 20:54, rsargent wrote:

Ok if Vincent agrees this is a bug I can make the issue and supply the test
fo.  The patch is his and I don't think I should claim it.


Glenn Adams-2 wrote

First, someone needs to open a bug and submit a patch against the bug.





--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563p36733.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


-
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: Does FOP-1.1rc1 change handling of RGB values?

[Rob Sargent]

Thanks for confirming that Chris.

I can no longer wait for the definitive answer on this issue and will 
proceedwith revamping our process w.r.t. colours in fo and pdf.


Cheers,

rjs

PS.  If it is a change in fop-1.1 I highly recommend it be mentioned 
(perhaps even high-lighted) in the release notes.


rj.
On 09/03/2012 08:37 AM, Chris Bowditch wrote:

On 31/08/2012 21:52, rsargent wrote:

Chris,

I'm not sure how to read this.  Are you endorsing string-replace as 
the way

to go to get cmyk into the pdf or was that meant to be tongue-in-cheek?


No I certainly was not endorsing string replace. I was intending to 
endorse the rgb-icc function.




I was about to switch over to using rgb-icc since we have two colour
profiles in play.  If you're suggesting that string-replace is 
preferrable,

then I really have to get the correct(ed) strings from somebody.


Thanks,

Chris




Chris Bowditch wrote


Definitely the right way to use FOP though :-)

Chris





--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Does-FOP-1-1rc1-change-handling-of-RGB-values-tp36690p36735.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






-
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: Does FOP-1.1rc1 change handling of RGB values?

[Rob Sargent]

You are of course correct.  I misspoke. We search in the pdf for the rbg 
color with an string such as this: "0.07843 0.15686 0.31372  rg".  And 
we would be replacing it with something like "0.08 0.00 0.15 0.0 k" if 
the rg string were found.


My apologies for mis-reading our code base.

rjs



On 08/29/2012 05:04 AM, Chris Bowditch wrote:

On 28/08/2012 18:02, rsargent wrote:

Perhaps I can rephrase the question.

Has the transformation of colour values from RGB (in the fo) to CMYK 
in the
pdf changed in fop-1.1rc1 compared with fop-1.0?  Our search and 
replace is

no longer finding the values in the pdf.  We insert temporary RGBs,
expecting to find known cymk definitions in the pdf for replacement. 
(Legacy

code).


FOP doesn't convert RGB to CMYK. If you could tell us what your code 
searches for in the PDF then we might have some chance to tell you if 
there has been a change to that




If I can't find a local explanation, I'm headed for a serious 
re-write of

color handling.  Should have been done long ago, I concede. Still not a
good time, um, er, corporately.


Definitely the right way to use FOP though :-)

Chris


Thanks

rsargent wrote

I'm not finding certain strings related to colour I expect to be in the
pdf.  Has this changed recently.  I didn't see mention of such in the
1.1 release notes.

Thanks,

rjs





--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/Does-FOP-1-1rc1-change-handling-of-RGB-values-tp36690p36724.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






-
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: using cmyk() in fop-1.1rc1 SOLVED

[Rob Sargent]

I will definitely take this under serious consideration.  We use two 
different profiles programmatically so this advice may be very timely, 
thank you.  I need to rework a "pipeline" just to get away from 
fake-RGB-later-stringreplaced-in-pdf plan.


Here I go conflating two issues again but...Did fop-1.1rc1 change the 
way it writes colours (cmyk) into the pdf?


rjs

On 08/28/2012 09:20 AM, Chris Bowditch wrote:

On 27/08/2012 17:07, Rob Sargent wrote:

Hi Rob,

Bingo. I was completely off-base in thinking it was an xslt function. 
Your suggestion works like a charm.  This helps clean up local 
colour-guessing a lot.


BTW, I strongly recommend using rgb-icc function instead of cmyk. The 
rgb-icc function achieves the same thing as cmyk, but has 2 key 
benefits over cmyk:


1. It is more flexible as it supports any named ICC Profile, not just 
uncalibrated CMYK
2. rgb-icc is part of the XSL-FO recommendation and therefore portable 
to other XSL-FO Formatters. cmyk function is custom to FOP.


Thanks,

Chris



THANKS,

rjs


On 08/27/2012 09:39 AM, Sergiu Dumitriu wrote:

On 08/27/2012 11:09 AM, Rob Sargent wrote:

Does anyone have at hand (a link to) an example of using the cmyk()
function.  All I get is "Could not find function: cmyk". Who supplies
this function?

Running from cli  ~/tools/fop/fop-1.1rc1/fop -xml doc-1.xml -xsl
/d3/support/config/stylesheet/prose.xsl -foout cmyk.fo

with this (attempted) call in my stylesheet:

   



Definitely not XSLT. The way you wrote this, it's not FOP that fails 
to find the function, but the XSLT engine that transforms XML into 
FO. Try something like:



   cmyk(0.0, 0.564, 0.529, 0.325)






-
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




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

Re: using cmyk() in fop-1.1rc1 SOLVED

[Rob Sargent]

Bingo.  I was completely off-base in thinking it was an xslt function.  
Your suggestion works like a charm.  This helps clean up local 
colour-guessing a lot.


THANKS,

rjs


On 08/27/2012 09:39 AM, Sergiu Dumitriu wrote:

On 08/27/2012 11:09 AM, Rob Sargent wrote:

Does anyone have at hand (a link to) an example of using the cmyk()
function.  All I get is "Could not find function: cmyk". Who supplies
this function?

Running from cli  ~/tools/fop/fop-1.1rc1/fop -xml doc-1.xml -xsl
/d3/support/config/stylesheet/prose.xsl -foout cmyk.fo

with this (attempted) call in my stylesheet:

   



Definitely not XSLT. The way you wrote this, it's not FOP that fails 
to find the function, but the XSLT engine that transforms XML into FO. 
Try something like:



   cmyk(0.0, 0.564, 0.529, 0.325)






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

using cmyk() in fop-1.1rc1

[Rob Sargent]

Does anyone have at hand (a link to) an example of using the cmyk() 
function.  All I get is "Could not find function: cmyk". Who supplies 
this function?


Running from cli  ~/tools/fop/fop-1.1rc1/fop -xml doc-1.xml -xsl 
/d3/support/config/stylesheet/prose.xsl -foout cmyk.fo


with this (attempted) call in my stylesheet:

  


with this CLASSPATH
$HOME/tools/fop/fop-1.1rc1/lib/xmlgraphics-commons-1.5rc1.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/xml-apis-ext-1.3.04.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/xml-apis-1.3.04.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/xercesImpl-2.7.1.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/xalan-2.7.0.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/servlet-2.2.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/serializer-2.7.0.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/commons-logging-1.0.4.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/commons-io-1.3.1.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/batik-all-1.7.jar:\
$HOME/tools/fop/fop-1.1rc1/lib/avalon-framework-4.2.0.jar:\
$HOME/tools/fop/fop-1.1rc1/build/fop.jar:\
$HOME/tools/fop/fop-1.1rc1/build/fop-sandbox.jar:\
$HOME/tools/fop/fop-1.1rc1/build/fop-hyph.jar:\
$HOME/.m2/repository/com/amirsys/book-printing/book-printing-core/1.0.45-SNAPSHOT/book-printing-core-1.0.45-SNAPSHOT.jar:\
$APPDIR/plugins/com.amirsys.utilities_4.9.0/lib/jaxen.jar:\
$APPDIR/plugins/com.amirsys.utilities_4.9.0/lib/jdom.jar:\
$APPDIR/plugins/com.amirsys.utilities_4.9.0/lib/log4j.jar:\
$APPDIR/plugins/com.amirsys.utilities_4.9.0/lib/acres-legacy.jar:\
$APPDIR/plugins/com.amirsys.console_4.9.0/fop/fop100/fop/lib/fop-hyph.jar:\
$APPDIR/plugins/com.amirsys.console_4.9.0/console.jar

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

Re: Does FOP-1.1rc1 change handling of RGB values?

[Rob Sargent]

Well there is a more detailed page, I found. But still no reference to cmyk. I 
would think what I am seeing would have been a serious regression. So still 
looking for local causes... 

.rjs

Sent from my iPad

On Aug 24, 2012, at 7:23 PM, Glenn Adams  wrote:

> On Sat, Aug 25, 2012 at 8:20 AM, Rob Sargent  wrote:
> Well that's tricky.
> 
> We do a dance here, probably no longer necessary since the advent of cmyk(), 
> where in we map the used RGB values, then later in our pipeline "correct" 
> them in the pdf using iText. (This pre-dates my employment here. Just 
> sayin'.)  None of the searched for "temporary colours" is found in the pdf 
> and the most significant change is rc1 (I've gone through the dozen local 
> files changed since the last release and am left grasping at straws such as 
> blame-third-party. :(
> 
> If I were you, I would assume 1.1rc1 has changed until proven otherwise. The 
> release notes are quite skimpy as you've probably noticed, and are based 
> pretty much only on the change log entries added to status.xml. 

Re: Does FOP-1.1rc1 change handling of RGB values?

[Rob Sargent]

Well that's tricky.

We do a dance here, probably no longer necessary since the advent of 
cmyk(), where in we map the used RGB values, then later in our pipeline 
"correct" them in the pdf using iText. (This pre-dates my employment 
here. Just sayin'.)  None of the searched for "temporary colours" is 
found in the pdf and the most significant change is rc1 (I've gone 
through the dozen local files changed since the last release and am left 
grasping at straws such as blame-third-party. :(


rjs

On 08/24/2012 06:11 PM, Glenn Adams wrote:

please be more specific

On Sat, Aug 25, 2012 at 8:06 AM, Rob Sargent <mailto:rsarg...@xmission.com>> wrote:


I'm not finding certain strings related to colour I expect to be
in the pdf.  Has this changed recently.  I didn't see mention of
such in the 1.1 release notes.

Does FOP-1.1rc1 change handling of RGB values?

[Rob Sargent]

I'm not finding certain strings related to colour I expect to be in the 
pdf.  Has this changed recently.  I didn't see mention of such in the 
1.1 release notes.


Thanks,

rjs


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

Re: spurious indentation with (small) text lose

[Rob Sargent]

THANKS!  I'll start with the patch, then leader, then revisit indent 
property and report first success.


My apologies for conflating two issues in this thread.  I had no 
business presuming they were related.


rjs


On 08/22/2012 04:23 AM, Vincent Hennebert wrote:

On 20/08/12 16:05, Rob Sargent wrote:

Do we agree that this portion of the thread (small data loss at page break)
really is an issue?

Yes, this is due to the text-indent property set on the block that is
broken over the two pages, that doesn't play well with the changing IPD
code.

You can:
. Remove the text-indent property, if you can live with the start of the
   paragraph being flush with the left margin;
. Replace the text-indent with an 
rjs


On 08/15/2012 11:53 AM, Rob Sargent wrote:

And now we have attached the smallest possible fo, with only
font-family="any" which shows the spurious text loss across a page break.
Note that the top of page 2 is slightly indented (not our intent) and is
missing text (in this case the single Âword "appears").

I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't until
I here you're not able to reproduce the problem!

Cheers,

rjs




On 08/15/2012 09:14 AM, Rob Sargent wrote:

Meanwhile...

IT WORKS.  I set column-count to 1 and set the (derogatory remark
redacted)  MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the time
I got back to the original document it had 7 text-free pages in succession.

Now, recall the title of this thread (swapping loss for lose of course): I
had hoped that the two issues were related  but no such luck. I expect to
have a funky-font free example by end of day. This is a real problem here
and I have a sinking feeling that I cannot correct it with layout tricks.

Thanks a ton,
rjs


On 08/15/2012 02:47 AM, Vincent Hennebert wrote:

On 14/08/12 23:20, Glenn Adams wrote:

On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert
wrote:


If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to reduce
the impact on performance. Something as small as 10 might be more than
enough for your needs.


Is it worth introducing the ability for the FOP operator to specify the
maximum recovery attempts via fop.xconf? Is it worth dividing this into two
settings, one for page breaking, another for line breaking?

I don't think it's worth the additional complexity of wiring a look-up
to a configuration variable. I'd rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.



I'd prefer not to have non-configurable magic numbers of this sort if
possible.

Vincent


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

Re: spurious indentation with (small) text lose

[Rob Sargent]

Do we agree that this portion of the thread (small data loss at page 
break) really is an issue?


rjs


On 08/15/2012 11:53 AM, Rob Sargent wrote:
And now we have attached the smallest possible fo, with only 
font-family="any" which shows the spurious text loss across a page 
break. Note that the top of page 2 is slightly indented (not our 
intent) and is missing text (in this case the single word "appears").


I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't 
until I here you're not able to reproduce the problem!


Cheers,

rjs




On 08/15/2012 09:14 AM, Rob Sargent wrote:

Meanwhile...

IT WORKS.  I set column-count to 1 and set the (derogatory remark 
redacted)  MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by 
the time I got back to the original document it had 7 text-free pages 
in succession.


Now, recall the title of this thread (swapping loss for lose of 
course): I had hoped that the two issues were related  but no such 
luck. I expect to have a funky-font free example by end of day. This 
is a real problem here and I have a sinking feeling that I cannot 
correct it with layout tricks.


Thanks a ton,
rjs


On 08/15/2012 02:47 AM, Vincent Hennebert wrote:

On 14/08/12 23:20, Glenn Adams wrote:
On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert 
wrote:



If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to 
reduce
the impact on performance. Something as small as 10 might be more 
than

enough for your needs.

Is it worth introducing the ability for the FOP operator to specify 
the
maximum recovery attempts via fop.xconf? Is it worth dividing this 
into two

settings, one for page breaking, another for line breaking?

I don't think it's worth the additional complexity of wiring a look-up
to a configuration variable. I'd rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.



I'd prefer not to have non-configurable magic numbers of this sort if
possible.


Vincent

-
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





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

Re: spurious indentation with (small) text lose

[Rob Sargent]

Interesting upshot: when a single-column textless page precedes the last 
page (all text, 2 column) it appears thao FOP is um, er, forgetting to 
go to two column mode. The last text page is filled with sentences which 
run from border to border, then eventually the two column directive 
kicks in and the second column is printed over the first (page-wide) 
column.  I can think of a couple of work-arounds (raise the 
MAX_RECOVERY_ATTEMPTS to 20 and revert to two column) or make a new 
layout definition for 'special textless pages near the end of a 
chapter'.  Regrettable nuisance either way.


Cheers,

rjs

On 08/15/2012 11:53 AM, Rob Sargent wrote:
And now we have attached the smallest possible fo, with only 
font-family="any" which shows the spurious text loss across a page 
break. Note that the top of page 2 is slightly indented (not our 
intent) and is missing text (in this case the single word "appears").


I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't 
until I here you're not able to reproduce the problem!


Cheers,

rjs




On 08/15/2012 09:14 AM, Rob Sargent wrote:

Meanwhile...

IT WORKS.  I set column-count to 1 and set the (derogatory remark 
redacted)  MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by 
the time I got back to the original document it had 7 text-free pages 
in succession.


Now, recall the title of this thread (swapping loss for lose of 
course): I had hoped that the two issues were related  but no such 
luck. I expect to have a funky-font free example by end of day. This 
is a real problem here and I have a sinking feeling that I cannot 
correct it with layout tricks.


Thanks a ton,
rjs


On 08/15/2012 02:47 AM, Vincent Hennebert wrote:

On 14/08/12 23:20, Glenn Adams wrote:
On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert 
wrote:



If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to 
reduce
the impact on performance. Something as small as 10 might be more 
than

enough for your needs.

Is it worth introducing the ability for the FOP operator to specify 
the
maximum recovery attempts via fop.xconf? Is it worth dividing this 
into two

settings, one for page breaking, another for line breaking?

I don't think it's worth the additional complexity of wiring a look-up
to a configuration variable. I'd rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.



I'd prefer not to have non-configurable magic numbers of this sort if
possible.


Vincent

-
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





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

Re: spurious indentation with (small) text lose

[Rob Sargent]

And now we have attached the smallest possible fo, with only 
font-family="any" which shows the spurious text loss across a page 
break. Note that the top of page 2 is slightly indented (not our intent) 
and is missing text (in this case the single word "appears").


I'm tempted to include the pdf (generated with 1.1rc1-VHx2) but won't 
until I here you're not able to reproduce the problem!


Cheers,

rjs




On 08/15/2012 09:14 AM, Rob Sargent wrote:

Meanwhile...

IT WORKS.  I set column-count to 1 and set the (derogatory remark 
redacted)  MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the 
time I got back to the original document it had 7 text-free pages in 
succession.


Now, recall the title of this thread (swapping loss for lose of 
course): I had hoped that the two issues were related  but no such 
luck. I expect to have a funky-font free example by end of day. This 
is a real problem here and I have a sinking feeling that I cannot 
correct it with layout tricks.


Thanks a ton,
rjs


On 08/15/2012 02:47 AM, Vincent Hennebert wrote:

On 14/08/12 23:20, Glenn Adams wrote:
On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert 
wrote:



If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to reduce
the impact on performance. Something as small as 10 might be more than
enough for your needs.


Is it worth introducing the ability for the FOP operator to specify the
maximum recovery attempts via fop.xconf? Is it worth dividing this 
into two

settings, one for page breaking, another for line breaking?

I don’t think it’s worth the additional complexity of wiring a look-up
to a configuration variable. I’d rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.



I'd prefer not to have non-configurable magic numbers of this sort if
possible.


Vincent

-
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




http://www.w3.org/1999/XSL/Format"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xmlns:xalan="http://xml.apache.org/xslt"; xmlns:tags="xalan://com.amirsys.printing.renderer.acres.ProseFigureReference" xmlns:ec="xalan://com.amirsys.utilities.ElementConversion">
  

  
  


  
  


  
  


  
  
  


  
  
  


  

  
  

  

  

    Section to be Named Later
  

  


  

  
Familial Tumor and Neurocutaneous Syndromes

  

  


  

  
Familial Tumor and Neurocutaneous Syndromes

  

  
  





  

  

  
  

  

  


  


  

  


  

  
  

  

  24-3. 
  Plexiform NF involving cervical nerve roots is depicted on graphic (left), coronal STIR scan (right).

  


  


  

  24-4. 
  Coronal autopsy (left) and coronal STIR (right) show plexiform NF of thoracolumbar nerve roots (autopsy courtesy R Hewlett, MD).

  

  

  


  



  

  

  
  

  


  

  

  

  
  

  


  

  

  24-5. 
  
Axial T1WI shows multiple small cutaneous NFs
http://www.w3.org/1999/XSL/Format"; s

Re: spurious indentation with (small) text lose

[Rob Sargent]

Meanwhile...

IT WORKS.  I set column-count to 1 and set the (derogatory remark 
redacted)  MAX_RECOVERY_ATTEMPTS to 10, which was lucky because by the 
time I got back to the original document it had 7 text-free pages in 
succession.


Now, recall the title of this thread (swapping loss for lose of course): 
I had hoped that the two issues were related  but no such luck. I expect 
to have a funky-font free example by end of day. This is a real problem 
here and I have a sinking feeling that I cannot correct it with layout 
tricks.


Thanks a ton,
rjs


On 08/15/2012 02:47 AM, Vincent Hennebert wrote:

On 14/08/12 23:20, Glenn Adams wrote:

On Tue, Aug 14, 2012 at 1:23 PM, Vincent Hennebert wrote:


If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to reduce
the impact on performance. Something as small as 10 might be more than
enough for your needs.


Is it worth introducing the ability for the FOP operator to specify the
maximum recovery attempts via fop.xconf? Is it worth dividing this into two
settings, one for page breaking, another for line breaking?

I don’t think it’s worth the additional complexity of wiring a look-up
to a configuration variable. I’d rather implement a more intelligent
analysis of the page sequence to determine if there will be an infinite
loop or not.



I'd prefer not to have non-configurable magic numbers of this sort if
possible.


Vincent

-
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: spurious indentation with (small) text lose

[Rob Sargent]

Certainly gives one hope!
We do have 6 consecutive pages in the current plan, so I may be up for 
the local patch.

I'll report back asap.


Thanks,

rjs

On 08/14/2012 02:23 PM, Vincent Hennebert wrote:

Hi Rob,

On 14/08/12 15:42, Rob Sargent wrote:

Do we at least agree that there is a problem?

Maybe not.

Short version: on the region-bodies that are meant to be empty (the
region-body elements from page masters ‘gallery6-page-[3-8]’ in the
latest document you attached), set the column-count to 1. Also, make
sure that no more than 5 such page masters ever consecutively follow
each other.

Long story: when FOP cannot fit any content on a page, it skips it and
moves on to the next page, hoping that that next page will be big enough
to accommodate some content.

If the next page cannot accommodate any content either, then FOP skips it
too and moves on to the next page, and so on, until it finds a suitable
page, /or/ it has skipped pages more than 5 times in a row.

The latter condition is to avoid entering an infinite loop, where FOP
would hopelessly look for a page that can accommodate content while all
the remaining pages of the page sequence actually have zero height.

If your pages have multiple columns, then take the text above and
substitute page with column.

This is the case of your sample document, where FOP gives up at the
second column of gallery6-page5. Which means that you cannot put more
than 2 such pages consecutively in your document.

Since the gallery pages are not meant to have a body, it doesn’t matter
whether you specify a column-count of 1 or 2. Setting it to 1 will allow
you to put up to 5 such pages in a row.

If this is still not enough, then you can change the
MAX_RECOVERY_ATTEMPTS constant in
src/java/org/apache/fop/layoutmgr/BreakingAlgorithm.java to whatever
suits your needs. Note that this constant is also used for line
breaking, so you may want to keep it reasonably low in order to reduce
the impact on performance. Something as small as 10 might be more than
enough for your needs.

In theory, you could avoid all that fiddling by giving a special
region-name to the gallery page-masters’ region-bodies, but some quick
experiments gave strange results on my side. I would have to investigate
a bit more to find out what’s happening exactly.

FOP could also be a little better at detecting a possible infinite loop,
by analysing the page sequence and finding out whether there will ever
be a suitable page, or if for example that page-sequence will always
produce an alternation of the two same non-suitable pages. But that’s
another story...


HTH,
Vincent



Cheers,
rjs

On 08/04/2012 03:46 PM, Rob Sargent wrote:

OK I have a attached an fo which is free of our special fonts which
addresses the variation of text loss to which I alluded in last post
(missing paragraphs across textless pages).  I get identical pdf from
fop-1.0 and fop-1.1rc1-VH, showing the same data loss.

Notice that the first page ends with a hyphenated word, yet the text picks
up three pages later with the a major heading, losing the continuation of
the hyphenated word plus the remainder of the sentence.  If one adds more
textless pages the data loss in creases.  There is no data loss if there are
only two consecutive textless pages.  The real version of this chapter (54
pages) has a sequence of 6 textless pages.

I've left the other three s-p-ms in the supplied fo, commented out.  You can
see the increase in data loss by adding (un-commenting) those back into play.

However, I do suspect that the problem demonstrated here is not the same
issue as first shown in this thread.  I believe they are similar, aside from
the fact of data loss: they are both dependent on the s-p-m ordering.

In case brother Vincent is listening in, there is but one overflow warning:

 WARNING: Content overflows the viewport of the fo:region-body on
 page 3 in block-progression direction by 24480 millipoints. (See
 position 29:126)

and you can see that this refers to the region-body of a "textless" page.
With additional textless pages there are additional overflow warning for the
successive region-body definitions.

If overflow is the problem; is this overflow from the post-hyphenation
content.  That's about the correct linear requirement (~ 2 lines of text)

I hope you are able to regenerate the problem now. We certainly can :)

Cheers,

rjs


On 08/03/2012 09:05 AM, Rob Sargent wrote:

Drats!  It's 100% reproducible here with necessary fonts.  Should I post
the pdf?  Lend you the fonts?

Note that fop1.1rc1-VH has been tried but production is still using fop-1.0.

We have multiple cases in production.  Also a variation of the problem
which is losing two paragraphs when the flow extends over multiple textless
pages.


Ever desparate,

rjs

On 08/03/2012 01:23 AM, Pascal Sancho wrote:

Hi,

Unless I missed something, I cannot reproduce what you describe.
did you tried it without VH's patch?

Re: spurious indentation with (small) text lose

[Rob Sargent]

Do we at least agree that there is a problem?

Cheers,
rjs

On 08/04/2012 03:46 PM, Rob Sargent wrote:
OK I have a attached an fo which is free of our special fonts which 
addresses the variation of text loss to which I alluded in last post 
(missing paragraphs across textless pages).  I get identical pdf from 
fop-1.0 and fop-1.1rc1-VH, showing the same data loss.


Notice that the first page ends with a hyphenated word, yet the text 
picks up three pages later with the a major heading, losing the 
continuation of the hyphenated word plus the remainder of the 
sentence.  If one adds more textless pages the data loss in creases.  
There is no data loss if there are only two consecutive textless 
pages.  The real version of this chapter (54 pages) has a sequence of 
6 textless pages.


I've left the other three s-p-ms in the supplied fo, commented out.  
You can see the increase in data loss by adding (un-commenting) those 
back into play.


However, I do suspect that the problem demonstrated here is not the 
same issue as first shown in this thread.  I believe they are similar, 
aside from the fact of data loss: they are both dependent on the s-p-m 
ordering.


In case brother Vincent is listening in, there is but one overflow 
warning:


WARNING: Content overflows the viewport of the fo:region-body on
page 3 in block-progression direction by 24480 millipoints. (See
position 29:126)

and you can see that this refers to the region-body of a "textless" 
page. With additional textless pages there are additional overflow 
warning for the successive region-body definitions.


If overflow is the problem; is this overflow from the post-hyphenation 
content.  That's about the correct linear requirement (~ 2 lines of text)


I hope you are able to regenerate the problem now. We certainly can :)

Cheers,

rjs


On 08/03/2012 09:05 AM, Rob Sargent wrote:
Drats!  It's 100% reproducible here with necessary fonts.  Should I 
post the pdf?  Lend you the fonts?


Note that fop1.1rc1-VH has been tried but production is still using 
fop-1.0.


We have multiple cases in production.  Also a variation of the 
problem which is losing two paragraphs when the flow extends over 
multiple textless pages.



Ever desparate,

rjs

On 08/03/2012 01:23 AM, Pascal Sancho wrote:

Hi,

Unless I missed something, I cannot reproduce what you describe.
did you tried it without VH's patch?
I note that my FOP substitutes some fonts, that an have some effect there.
I attach the output (pdf from FOP trunk, without patch and without
your fonts), so you will see if there is something wrong in it.


2012/8/2 rsargent:

We've hit this a couple of times now and I have a small fo showing the
problem.

In production we are using fop-1.0, but I've generated this on both
1.0 and 1.1rc1 (with a small patch from Vincent related to
http://apache-fop.1065347.n5.nabble.com/page-number-is-stuttering-tt36312.html
page-number-stutters  )

See the top of the second page of the generated pdf: the text is indented ~
5 chars and missing the word "appears".

The full sentence is shown below.
 
   While most PNFs remain benign, between 10-15% become
malignant. Deep-seated PNFs are at particular risk for development
   http://www.w3.org/1999/XSL/Format";
font-weight="bold">MPNST
   .  MicroRNA misregulation appears to be a critical event
in the malignant transformation of PNFs.
 

I apologise for the funky fonts, but this problem is so delicate
w.r.t. content that I cannot switch out my fonts at this time.

The juxtaposition of the two simple-page-masters is critcal.  The
gap/loss always appears on the "three-side" page layouts. I have
removed any overflows (Vincent ;) ) so I don't thing that as the problem.

http://apache-fop.1065347.n5.nabble.com/file/n36563/short.xml  short.xml




-
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: page-number is stuttering

[Rob Sargent]

Ever helpful. Thanks a ton.

The italics-outside-the-box is not an issue here, more a curiosity.  
I'll try other fonts to see what affect that has.


Now that I understand the value of the line numbers, I make good use of 
them by running from the commandline and trapping the output.  (I must 
turn down the logger though because fop1.1rc1-VH is generating 700Mb log 
files!)


I've drastically reduced the overflow, at least for the parts which I 
can control.  I had been using fixed height in certain components and 
these were involved in the vast majority of the overflow.  Since we are 
at a point in our process where clipping the content is no longer 
desirable I have removed the height restrictions (and overflow=hidden) 
and am much cleaner now.


In the parallel thread, "Spurious indentation with (small) text 
lose[sic]" you can find example fo with no over /except /for the 
region-body.  Unfortunately the affected region-body elements are not 
supposed to have any text.  My guess is that overflow is the fragment of 
data being lost.  I suspect also this same situation was in play with 
your patch.  Since I have removed the bulk of the overflow fop-1.0 still 
produces page-number stutters and that may still be as you point out due 
to the overflow - again on region-body elements which have zero sized.


My bet is that both my issues are tied to the same flaw, with apparently 
separate manifestations.


Welcome home :)

rjs


On 08/09/2012 01:18 PM, Vincent Hennebert wrote:

Fix committed in rev. 1371386:
http://svn.apache.org/viewvc?rev=1371386&view=rev

See also Bugzilla 53688: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53688

As to your other questions:

On 20/07/12 22:49, Rob Sargent wrote:

Saint Vincent, you deliver us again. The patch works on the original fo! (One
vote from here for committing the patch)

About the overflow:

  * All the incidents I've looked at are in the captions under the
header or in the page header.  Would overflow in these static
regions the cause of the page stutter?

No. The stutter was caused by an overflow in the region-body.



  * Said captions are rendered in font-style="italic".  Placing a border
around the image captions I find that the slant forces the bottom of
the first letter of each line outside the border. Is this not a bug?
For instance if I had another element abutting the caption, the
first letter of each line would overlap that abutting element.

Difficult to tell without having the font. There might be a bug in
reading the font metrics, but it’s more probable that the glyph’s
outline sticks out of the bounding box. In other words, that the glyph
is bigger than it pretends to be. A solution could be to add some
padding to the element that has the border.



  * The border on the caption does get clipped (2/3 of the time the
sides and the bottom does not appear in the printout), but I'm at a
loss to see why.  There's plenty of room according to what is shown
if I add a background colour to the caption text block and a
different colour for the static region.

I’m not sure what you are referring to. You may want to mention this
issue in a new thread (if you haven’t already done so).



  * Btw, when running the application in IntelliJ all the overflow
messages show as being at position(-1, -1), so that was rather
confusing.

This is probably because you pipe the result of the XSLT straight to
FOP, without saving it to a file. In that case there is no information
about line and column. If you save it to a file and format it nicely,
then you will get useful information about the locations of problems.

HTH,
Vincent



And another definitions of overflow: the log of my full-chapter fo was 450M!


On 07/20/2012 04:37 AM, Vincent Hennebert wrote:

I've run out of the time I can allocate to this issue I'm afraid. I have
a fix but it needs to be cleaned up and tested.

The best way to avoid the problem is to fix all the overflow warnings
that you are getting. You probably want to fix them anyway since it may
lead to a better output.

If constraints prevent you from fixing them all, then you can try the
attached patch against the latest trunk. It should be fairly safe in the
sense that it doesn't modify the layout engine's behaviour, only the
overflow reporting mechanism. That said, it's untested and unsupported
:-)

In the future, one thing that would be of great help when you submit FO
files would be to replace all the custom fonts with the default ones:
serif, sans-serif, monospace. That will avoid a lot of noise in the
warnings, but most of all allow us to reproduce the exact same layout as
you have.


Thanks,
Vincent


On 19/07/12 22:09, Rob Sargent wrote:

A prince you are!

I do have many of those messages, some are very regular (same 7200pt overflow)
and must be from a repeated element.  Others are more varied are hence more

Re: spurious indentation with (small) text lose

[Rob Sargent]

Drats!  It's 100% reproducible here with necessary fonts.  Should I post 
the pdf?  Lend you the fonts?


Note that fop1.1rc1-VH has been tried but production is still using fop-1.0.

We have multiple cases in production.  Also a variation of the problem 
which is losing two paragraphs when the flow extends over multiple 
textless pages.



Ever desparate,

rjs

On 08/03/2012 01:23 AM, Pascal Sancho wrote:

Hi,

Unless I missed something, I cannot reproduce what you describe.
did you tried it without VH's patch?
I note that my FOP substitutes some fonts, that an have some effect there.
I attach the output (pdf from FOP trunk, without patch and without
your fonts), so you will see if there is something wrong in it.


2012/8/2 rsargent :

We've hit this a couple of times now and I have a small fo showing the
problem.

In production we are using fop-1.0, but I've generated this on both
1.0 and 1.1rc1 (with a small patch from Vincent related to
http://apache-fop.1065347.n5.nabble.com/page-number-is-stuttering-tt36312.html
page-number-stutters  )

See the top of the second page of the generated pdf: the text is indented ~
5 chars and missing the word "appears".

The full sentence is shown below.
 
   While most PNFs remain benign, between 10-15% become
malignant. Deep-seated PNFs are at particular risk for development
   http://www.w3.org/1999/XSL/Format";
font-weight="bold">MPNST
   .  MicroRNA misregulation appears to be a critical event
in the malignant transformation of PNFs.
 

I apologise for the funky fonts, but this problem is so delicate
w.r.t. content that I cannot switch out my fonts at this time.

The juxtaposition of the two simple-page-masters is critcal.  The
gap/loss always appears on the "three-side" page layouts. I have
removed any overflows (Vincent ;) ) so I don't thing that as the problem.

http://apache-fop.1065347.n5.nabble.com/file/n36563/short.xml short.xml




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

content oveflow on a textless page

[Rob Sargent]

FOP-1.0 and FOP-1.1rc1 both showing this

Where "textless page" is one on which the region-body is of zero size.

Is the overflowing content in fact from the most recent textful page?

Though the reported overflow is rather small (typically 1/3 of an inch 
or so), we lose as much as two paragraphs of text.


FOP reports:
[FOUserAgent] [main] [2012-08-02 13:29:44,886] WARN  - Content overflows 
the viewport of the fo:region-body on page 24 in block-progression 
direction by 45204 millipoints. (See position 120:126)


And the definition of that page (line 120 of the fo) is:
master-name="gallery6-page-24" margin=" 0.0in 0.833in 0.0in 0.0in">
  margin-top="10.99in" column-gap="0.40in" column-count="2" />
  region-name="header-gallery6-page-24" />



OK, I admin there is room for 0.01 inch of text..



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

Re: spurious indentation with (small) text lose

[Rob Sargent]

Of course the subject should have read "(small) text loss"

On 08/02/2012 11:56 AM, rsargent wrote:

We've hit this a couple of times now and I have a small fo showing the
problem.

In production we are using fop-1.0, but I've generated this on both
1.0 and 1.1rc1 (with a small patch from Vincent related to
http://apache-fop.1065347.n5.nabble.com/page-number-is-stuttering-tt36312.html
page-number-stutters  )

See the top of the second page of the generated pdf: the text is indented ~
5 chars and missing the word "appears".

The full sentence is shown below.
 
   While most PNFs remain benign, between 10-15% become
malignant. Deep-seated PNFs are at particular risk for development
   http://www.w3.org/1999/XSL/Format";
font-weight="bold">MPNST
   .  MicroRNA misregulation appears to be a critical event
in the malignant transformation of PNFs.
 

I apologise for the funky fonts, but this problem is so delicate
w.r.t. content that I cannot switch out my fonts at this time.

The juxtaposition of the two simple-page-masters is critcal.  The
gap/loss always appears on the "three-side" page layouts. I have
removed any overflows (Vincent ;) ) so I don't thing that as the problem.

http://apache-fop.1065347.n5.nabble.com/file/n36563/short.xml short.xml




--
View this message in context: 
http://apache-fop.1065347.n5.nabble.com/spurious-indentation-with-small-text-lose-tp36563.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




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

How to set hyphen base url in config file

[Rob Sargent]

Such that I can enable hyphenation when running fop (1.0) from the 
command line.  We're currently calling factory.setHyphenBaseUrl() in our 
programme and I need the same when running tests from the command line


Thanks,
rjs


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

Re: page-number is stuttering

[Rob Sargent]

Saint Vincent, you deliver us again. The patch works on the original fo! 
(One vote from here for committing the patch)


About the overflow:

 * All the incidents I've looked at are in the captions under the
   header or in the page header.  Would overflow in these static
   regions the cause of the page stutter?
 * Said captions are rendered in font-style="italic".  Placing a border
   around the image captions I find that the slant forces the bottom of
   the first letter of each line outside the border. Is this not a bug?
   For instance if I had another element abutting the caption, the
   first letter of each line would overlap that abutting element.
 * The border on the caption does get clipped (2/3 of the time the
   sides and the bottom does not appear in the printout), but I'm at a
   loss to see why.  There's plenty of room according to what is shown
   if I add a background colour to the caption text block and a
   different colour for the static region.
 * Btw, when running the application in IntelliJ all the overflow
   messages show as being at position(-1, -1), so that was rather
   confusing.

And another definitions of overflow: the log of my full-chapter fo was 450M!


On 07/20/2012 04:37 AM, Vincent Hennebert wrote:

I've run out of the time I can allocate to this issue I'm afraid. I have
a fix but it needs to be cleaned up and tested.

The best way to avoid the problem is to fix all the overflow warnings
that you are getting. You probably want to fix them anyway since it may
lead to a better output.

If constraints prevent you from fixing them all, then you can try the
attached patch against the latest trunk. It should be fairly safe in the
sense that it doesn't modify the layout engine's behaviour, only the
overflow reporting mechanism. That said, it's untested and unsupported
:-)

In the future, one thing that would be of great help when you submit FO
files would be to replace all the custom fonts with the default ones:
serif, sans-serif, monospace. That will avoid a lot of noise in the
warnings, but most of all allow us to reproduce the exact same layout as
you have.


Thanks,
Vincent


On 19/07/12 22:09, Rob Sargent wrote:

A prince you are!

I do have many of those messages, some are very regular (same 7200pt overflow)
and must be from a repeated element.  Others are more varied are hence more
likely to be in the flow perhaps? Since as you point out they are not page
numbers, is there anything I can do, e.g. command line params, debug levels to
help me pin-point the errant content?

Counting this one as under control, I still have one more issue for which I
think there is an page break problem.  Still working on a small repeatable
offender.

Cheers,

rjs




On 07/19/2012 02:26 PM, Vincent Hennebert wrote:

Hi Rob,

Thanks for your efforts to reduce the size of the FO file, this is
really appreciated.

I believe I found the problem, but need to investigate a bit more. In
the meantime, try to modify the content so that it doesn't overflow the
page. Watch for messages saying 'Content overflows the viewport of the
fo:region-body on page n'. Except that 'n' is not the page number... but
the column number!

If you can avoid page overflows, you should avoid triggering the issue
and get appropriate page numbers.

HTH,
Vincent


On 19/07/12 20:33, Rob Sargent wrote:

I have whittled the fo down further (shorter-fop.xml, now 35%) of original,
but this is as small as I can go to reproduce the exact 3-page stutter.  I can
remover one more page and get a single stutter (shortest-fop.xml)

I pray this will be enough.

Thanks a bunch.


On 07/19/2012 12:51 PM, Rob Sargent wrote:

I truly regret the large fo;  I know it hampers things at debug time.  I had
to find a particular starting point such that the content was still aligned
with the original placements.  I'll try to trim more pages from after the
page numbering problem.

rjs


On 07/19/2012 01:31 AM, Pascal Sancho wrote:

Hi,

To be efficient, a short fo helping to reproduce the issue should be
attached to the bug entry, so opening a bug rather than ask on this
list doesn't help anymore if the material remains the same.
I (or somebody else) have to look closer into the fo you attached
here,  then perhaps I (or somebody else) will, or will not, find a bug
causing this issue. Since the use case is quite big, that will take
some extra time :/

2012/7/18 Rob Sargent :

My apologies, but I've been unable to shrink this to a small test.  I'm
forced to send a rather large fo, but that's my level of desperation. Or
should I open a bug report?

rjs




On 07/12/2012 09:20 AM, Rob Sargent wrote:

I will do my best, but I see nothing in the generated fo that strikes me as
suspicious.

See other post on not getting identical output from commandline, which is
hampering generating reliable tests.

Anecdote:  prior to the 3 pages of stutter there a