Re: FOP - page 2 not displayed when there is no overflow from page 1

[Andreas Delmelle]

Hi

Kind request/reminder:
Please use fop-users@ for general usage questions. Thanks!

Now that that is out of the way:

> On 29 Nov 2017, at 06:59, gauravabburi  wrote:
> 
> I am trying to generate a PDF with multiple pages. I have a static page 2
> which is to be generated even when there is no overflow from page 1.
> However, that is not happening. 
> In case there is an overflow from page 1, I want it to be displayed in page
> 3.
> Page 1 -> "first"
> Page 2 -> "terms"  - static page
> Page 3 -> "rest"   -  overflow from Page 1
> Code snippet :



Off the top of my head, I would say that the most straightforward way to always 
force that second page would be to set the "force-page-count" attribute on the 
fo:page-sequence. See: https://www.w3.org/TR/xsl/#force-page-count

A value of "even" or "end-on-even" should suffice to make it work, possibly in 
combination with an additional page-master for "blank" last pages if they are 
not the second.
So, an unavoidable consequence of this approach is that this will generate an 
extra blank page at the end, if the content were to end on an odd page... If 
you can live with that, this should be enough to guarantee that the second page 
will always be included.


Hope this helps!


Greetz


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

Re: Place image at top of page

[Andreas Delmelle]

Hi Michel

Sorry to chime in so late on this...

> On 25 Nov 2016, at 17:11, Michel Krämer  wrote:
> 
> I'm looking for a way to place an image at the top of the page, just like you 
> can do it in LaTeX:
> 
> ...
> 
>  ...
> 
> 
> I understand that FOP does not support the "before" value yet.
> 
> Is there a workaround to achieve the same thing? For example by placing the 
> image absolutely or something like that?

Not really, I'm afraid. If the box is absolutely positioned then it will 
overlap with the other content... :(

> 
> I had a look at the code and it seems the feature is almost implemented but 
> not fully yet. There is a BeforeFloat class that is supposed to place blocks 
> in the before-float area, but even if I use  this 
> class never receives any children. The float also disappears from the output 
> PDF.
> 
> If there is no workaround for my problem I would be very interested to 
> implement the solution myself. I'm a Java programmer and if anyone could give 
> me some pointers on where to start and what is missing in the current code 
> I'd probably be able to fill the gaps.
> 
> Let me know what you think. Thank you so much!

I cannot recall immediately to what extent the feature is implemented at this 
point, but since start-floats are already implemented, that means there is 
already a mapping for the fo:float element, so no need to worry about that. 

I do recall from past discussions that the "simplest" solution would be to 
treat before-floats very much in the same way as footnotes, only instead of the 
eventual layout element list being appended to the 'current' page, the list 
would be prepended.

So, that would be one important clue: try to focus on getting to understand 
which flow a footnote follows in the code, and you should have a template to 
work off of. Ideally, we want to make sure that code that can be shared, is 
also shared, so do not hesitate to introduce a common superclass for 
FootnoteLayoutManager and BeforeFloatLayoutManager, or something like that, if 
that can save some copy-pasting...

Eventually, for the line layout algorithm, it does not yet matter _where_ on 
the page the float will end up, only that it is out-of-line content that 
(basically) has no effect on the line breaks, it only needs to be anchored to a 
line box.
For the page breaking algorithm, same as footnotes, it does not matter _where_ 
on the page the float should end up, just how much space it will take up, if 
included.

Only in the last layout phase, when adding the areas to the tree, the paths of 
before-float and footnote diverge.

Hope the above info helps already. If you start nosing around, and/or have 
other questions or an idea that you want to bounce back, do subscribe to 
fop-dev, and follow up there.


Cheers

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

Re: fox:orphan-content-limit/

[Andreas Delmelle]

Hi

Apologies for the delayed response, but noticed this one was still unanswered...

> On 6 Dec 2016, at 11:39, kiranps  wrote:
> 
> Hi ,
> 
> Could you please share working example for fox:orphan-content-limit and
> fox:widow-content-limit. I had tried to use these but not working so far.

There should be an example available in FOP's layoutengine test suite, e.g.:

http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/fop/test/layoutengine/standard-testcases/table_fox_orphan-content-limit_1.xml?view=markup

Do note, however -- I noticed this at one point, while looking at decent 
support for the standard widows/orphans properties -- that the fox:* attributes 
have been implemented 'in reverse' as it were. That is: orphan-content-limit 
should actually be called widow-content-limit, and vice versa... As far as I 
know, this was never corrected, and could also explain why you are running into 
issues (?)


Hope that helps!

Cheers

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

Re: XSLT param for FOP pdfprofile parameter

[Andreas Delmelle]

Hi Stefan

> On 22 Jul 2016, at 23:21, Stefan Hegny (hydrografix Consulting GmbH) 
>  wrote:
> 
> Hi Andreas,
> 
> one more idea:
> Put the other way round, there's also no way to force a specific pdfprofile 
> from a fo?

Correct. It is just an additional output option for FOP's PDF renderer, and as 
such not covered by XSL-FO (although one could conceivably use the 
fo:declarations section to carry that info, but that too would require an 
extension to be written, and still, it would not be automatically available in 
the XSLT stage)

> Where the xsltransform could insert it depending on a param?

Yep, and what I was thinking of, is that based on that XSLT parameter, the 
user/stylesheet author would be able to conditionally generate different FO. 
For example, if you know that certain FO constructs would lead to PDF that does 
not conform to PDF/A-1a, then if that parameter is passed to the XSLT process, 
one could take that into account and use a different set of templates.

If those additional output options were _always_ passed by FOP to the XSLT 
processor via JAXP, say as parameters with a name prefixed with 'fop-output-' 
or something along those lines, then it can be documented and every user would 
have those available, if needed.

Just my 2 cents...


Cheers

Andreas

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

Re: XSLT param for FOP pdfprofile parameter

[Andreas Delmelle]

Hi Stefan

> On 22 Jul 2016, at 16:09, Stefan Hegny (hydrografix Consulting GmbH) 
>  wrote:
> 
> Hello,
> would like to know if when calling fop (2.1) with -pdfprofile 'PDF/A-1a' 
> (e.g.)
> this value is also somehow available to a xalan xslt transform that is invoked
> by fop when using -xsl stylesheet.xsl -xml input.xml. Or do I have to declare
> it in xslt manually somehow and set by -param mypdfprofile .. somehow.

The latter, I'm afraid. The output format is only available to FOP itself, and 
not passed to the XSLT (pre-)processor.

That said, I don't think it would be too hard to build that into FOP as it uses 
JAXP, but given that our current PMC chair seems to be of the opinion that it 
was a mistake to add support for XML+XSLT input as a convenience for the users 
in the first place, it could turn out to be a tough sell...


Cheers

Andreas


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

Re: Scrollable region in generated PDF

[Andreas Delmelle]

Hi

> On 19 Jul 2016, at 18:48, GK  wrote:
> 
> I'm using Apache FOP to generate a PDF through XML and XSL-FO. I have a cell
> in my generated PDF that I need to be able to scroll through if the content
> overflows it. XSL-FO has an overflow="scroll" feature, but based on my
> research on the topic it seems that Apache FOP does not support this option. 
> 
> Is there any way to enable this feature in Apache FOP?

Right now, AFAIK, no. :(

> Is it possible to enable it in the source code?

If PDF supports it, then probably yes, but... this requires some familiarity 
with the source code. Personally, I am not even sure whether this is possible 
in PDF. If it is, then if one is familiar with the PDF spec, it would probably 
be possible to make FOP support it.

> Any other ways to tackle this issue (ie some sort of post-processing or 
> converting between different formats that I could
> try)?

Not sure here. It all depends on whether the PDF spec supports this in the 
first place... I would have to check myself if it does, so if anybody knows the 
answer to this and can save us some time, feel free to chime in.


Cheers

Andreas

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

Re: SVG text not displaying in PDF

[Andreas Delmelle]

Hi Jeremy

> On 28 Apr 2016, at 22:40, Jeremy Heiler  wrote:
> 
> I am in the process of upgrading from FOP 0.92-beta to 2.1, and for the most 
> part I have been able to work out the issues. However, I am stumped with this 
> particular issue of rending text in an SVG. Any SVG text that used to render 
> no longer displays at all. 
...
> What am I missing?

Hmm... difficult to say without seeing the FO source. Is it possible for you to 
post a reduced sample that demonstrates the issue?


TIA

Andreas

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

Re: Displaying different languages in PDF

[Andreas Delmelle]

Hi

> On 28 Mar 2016, at 13:18, Sunrita Bagchi Basu  wrote:
> 
> Hi,
> 
> I have to display texts of various languages e.g. Chinese, japanese, Korean, 
> Spanish, etc
> I added font-family="Calibri, 'MS Mincho', Batang, serif, SimSun" in the 
> xsl:fo file, though didn't install/embed any fonts. This worked when running 
> in Windows. 
> But the same fails to work within a Tomcat server in centOS.
> it shows errors such as :
> catalina.out:[WARN] Glyph "杰" (0x6770) not available in font "Times-Roman".
> 
> catalina.out:[WARN] Glyph "出" (0x51fa) not available in font "Times-Roman".
> 
> catalina.out:[WARN] Glyph "班" (0x73ed) not available in font "Times-Roman".
> 
> 
> 
> I have not mentioned Times-Roman to be used as the font, so I am a bit 
> confused how is this one getting picked?

"Times-Roman" is the default Base14 font that is used for "serif", that is why. 
It indicates that none of the other specified font-families are available in 
that environment. On Windows, if you have font auto-detection enabled, they are 
all available, which explains why it works in one environment, but not in the 
other.

One solution would be to make sure all those font files are available in a 
location where they can be reached from within the servlet context.

Hope this helps!


KR

Andreas

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

Re: o.a.f.i.loader.batik.PreloaderSVG - Error while trying to load stream as an SVG file: Invalid byte 1 of 1-byte UTF-8 sequence.

[Andreas Delmelle]

Hi

> On 07 Mar 2016, at 12:03, Bram Maes  wrote:
> 
> Image is not rendering in pdf.  In the logs this is what I see:
> 
> 11:57:24.293 DEBUG o.a.x.i.l.i.AbstractImageSessionContext - Creating new 
> Source for images/logo_nl.png
> 11:57:24.307 DEBUG o.a.f.i.loader.batik.PreloaderSVG - Error while trying to 
> load stream as an SVG file: Invalid byte 1 of 1-byte UTF-8 sequence.
> 11:57:24.311 DEBUG o.a.x.i.l.i.AbstractImageSessionContext - Returning Source 
> for images/logo_nl.png
> 11:57:24.313 DEBUG org.apache.fop.fo.FONode - Invalid element: 
> fo:external-graphic inside foreign xml markup

Not sure if that is the cause of the error, but seems like you are embedding an 
fo:external-graphic inside an instream SVG element (?) 
That would not be the correct way to approach this. If you want to reference a 
binary (JPG, PNG or GIF) from within an instream SVG element, you should stick 
to using SVG, and not try to reference it via an XSL-FO mechanism. An SVG 
itself can be referenced as a fo:external-graphic, but then in its entirety, 
not partially...


Hope this helps!

KR

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

Re: keep-together question

[Andreas Delmelle]

Hi Matthew

While I can't speak to the integer-keep support, from what I can make out here, 
it does seem like you would be greatly helped by decent orphans/widows support.

Assuming that you know that at most N lines will fit together on a page, you 
could specify orphans="N" on the parent block, which will have exactly the 
effect I think you are seeking. That is: if a paragraph/block ends, and there 
is no more room for N lines, the next paragraph would automatically start on a 
new page, but would still allow breaking after the Nth line (in other words: it 
acts like a keep-together on the first N lines in a block). You could play with 
slightly lower values to avoid leaving too much empty space on a page, or 
combine with a widows="..." setting for paragraphs that you know will take up 
multiple pages. It would still require a couple of tries to arrive at the 
nicest looking result, but at least, it is a bit less black-and-white than a 
forced keep-together of the entire block.

First, the bad news: FOP 2.1 (and trunk) still does not support that.

The good news: there is a patch available in JIRA (look for FOP-1488), which I 
worked on quite some time back, and which I believe one of our committers 
--Matthias-- is already using. It will take a quick stroll, probably, to make 
sure it can easily be applied to trunk. I synched it up last year, and as I 
recall, not a lot has changed since then to those areas in the code, so I'll 
see if I can at least update that shortly. I really should work on committing 
it to trunk anyway, so we can finally close that and at least get it in for a 
next release.

Just one question left: Are you fluent enough in Subversion, Ant etc. to check 
out the trunk, apply the patch and build FOP, or would you require a binary 
package to try it out? I guess I could always (temporarily) attach one in JIRA 
for you to download, or deliver it some other way, if that helps.

Let me know.


Andreas

> On 25 Feb 2016, at 19:12, Matthew R. Wilson  wrote:
> 
> On Thu, Feb 25, 2016 at 09:41:20AM +0100, Pascal Sancho wrote:
>> That can be achieved using an integer value rather than 'always'.
>> See [1] (compliance page) & [2] (XSL-FO rec v1.1) for further info.
>> 
>> NOTE: keep-together should be considered as a shorthand for
>> *.within-line, *.within-column, and *.within-page
> 
> I've tried using an integer value, but that doesn't seem to do anything.
> For example, changing my original example attachment to the following
> snippet
> 
>  
>line 1
>line 2
>
>line n
>  
> 
> does not do what I expect. Even though this block can fit on a page, I
> don't end up with a page break before it and it just breaks in the
> middle. The same block with keep-together.within-page="always" results
> in the expected page break before the block. I've removed all other
> keeps in the document so there shouldn't be anything conflicting with
> the attempt to make this block appear on its own page.
> 
> The FOP compliance page says that there is "Minimal support for
>  values", but I don't see anything explaining further. So I'm
> back to not knowing if I'm just not doing it right (i.e. is there
> something more to it than changing "always" to "100"), or am I hitting a
> scenario that isn't supported by the minimal support.
> 
> Thanks,
> Matthew
> 
> 
> -
> 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: changing the look of the PDF output by FOP

[Andreas Delmelle]

Hi Peter

To add to what Glenn already answered, we can tell that you are using Docbook 
XSLT to handle the XML to XSL-FO conversion. 

Now, Docbook is one way to achieve that. Another would be to write your own 
XSLT stylesheets. Not every subscriber to this list is also fluent in Docbook, 
though, so in order to get help specifically on tweaking Docbook to change the 
output, it is recommended to post the questions on their mailing lists. 
Do mind that they also have an FAQ section, that they will expect you to have 
browsed before posting your questions.

See also: http://docbook.sourceforge.net 

A good reference for learning about Docbook, is Bob Stayton's book, which is 
available in HTML online: http://www.sagehill.net/docbookxsl/


Hope this helps!

KR

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

Re: [ANN] Apache FOP 2.1 Released

[Andreas Delmelle]

Hi Radu

> On 15 Jan 2016, at 12:52, Radu Coravu  wrote:
> 
> Hi Simon,
> 
> Thanks, great news. I took it for a spin and it worked in my case (PDF of 
> about 1500 pages).
> Also the NPE I encountered using FOP 2.0 seems to be fixed:
> 
> https://issues.apache.org/jira/browse/FOP-2461
> 
> although it does not yet seem to have the resolved state in the JIRA tracker.

Yeah, indeed... If you look closer in the comments, I committed a fix a while 
back since multiple users were reporting being affected by it, but kept that 
open, since I was not really satisfied with the robustness of the fix. 
Thinking more about it now, perhaps we can resolve this particular one, and 
create a new, linked issue for a more thorough solution. As I recall, someone 
may have already posted a suggestion/patch (?)

KR

Andreas

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

Re: Memory and page-sequences

[Andreas Delmelle]

> On 05 Jan 2016, at 22:09, robrez  wrote:
> 
> I was delighted to learn that fop 2.0 has been released (I live under a
> rock).
> 
> For some time now we've been manually breaking up our content into multiple
> page-sequences -- many more than we would like to use.
> 
> I saw that one long page-sequence still eats memory:
> https://xmlgraphics.apache.org/fop/2.0/running.html#memory
> 
> For years now, I've been using a less-than-ideal strategy to break my
> content up into multiple page-sequences. I'm wondering if there is any hope
> that we will be able to stop doing this at some point and let the pages
> break naturally.

Not in the near future, I'm afraid... It would require a very thorough rework 
of the line- and page-breaking interaction. 

At any rate, barring forced page-breaks, what happens is that first ALL line 
breaks for the entire page-sequence are determined, and only then is control 
handed over to the page-breaking algorithm, which in turn computes the 
page-breaks based on the line-boxes. 
There have been lots of theories/ideas on improving that, but one thing is 
certain: it should start with making the basic line-breaking process 
interruptible. As long as that is not the case, it is virtually impossible to 
improve this.
Roughly: if it is more or less a certainty that there are enough line-boxes to 
fill the current page, return control to the page-breaking algorithm, so that 
there is at least an opportunity to flush, and e.g. detect page-width changes 
much earlier. Right now, such changes are only detected after all the 
line-breaks have been computed once... If they occur, the line-breaking process 
is restarted as of the point where the page-break to a new page with different 
inline-progression-dimension occurred. In the end, that could very well mean 
that a set of hundreds of line-breaks are computed for nothing, just wasting 
memory and CPU cycles.

Definitely not a trivial matter to resolve.


KR

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

Re: FOP Special characters rendering

[Andreas Delmelle]

> 
> Haven't used it in a while, but the "font-family" attribute allows multiple 
> fonts to be specified, with the later ones as a fallback if the characters 
> are not available in the former. So maybe you are lucky with specifying 
> "Helvetica, Symbol"... When I used it years ago there was a small catch, 
> namely that FOP stayed in the fallback font as long as it also contained the 
> subsequent characters (which was not exactly what I wanted). So if, for 
> example, your symbol was followed by digits, which are also present in the 
> symbol font, they would have be rendered with this font (looking different to 
> Helvetica's digits). I don't know whether this has been solved in the 
> meantime.

Yeah, and there is another catch I noticed if you stick with the Base14 fonts 
and switch between Symbol and Helvetica (or Times): the baseline alignment of 
the symbols seems to be a bit out of whack, unless you use explicit fo:inlines, 
which somehow automagically corrects this. No such issue with the TrueType 
Symbol font on my system, though...

In the mentioned case for the OP, it seems as if he may be best off using a 
Unicode font that contains glyphs for a very wide range of codepoints. Depends 
a bit on what platform you are on, but if it is Windows, then a font like 
'Arial Unicode' should do the job, I think. With font auto-detection, one 
should be able to use most of the system-installed fonts. (Note - Have a JIRA 
issue open --FOP-2540-- to improve this on OS X (and possibly also Linux), 
which has several fonts using different CTABs than Windows; or better: similar 
CTABs, but simply with a non-supported platform/encoding ID...)



KR

Andreas

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

Re: Migration from FOP 1.0 to 2.0

[Andreas Delmelle]

Hi

> On 04 Nov 2015, at 10:25, Mandar Nimbkar  wrote:
> 
> HI,
> Your help on this is highly appreciated ..

> I am migrating from FOP 1.0 to FOP 2.0
>  
> I have made the required Java code changes as per the changed API.
>  
> There are PNG images used in the report generated using PDF renderer..
>  
> Here is the FOP config

>  
>   
>  class="org.apache.xmlgraphics.image.loader.impl.ImageLoaderRawPNG"/>
>  class="org.apache.xmlgraphics.image.loader.impl.ImageLoaderPNG"/>
>   
>  
> 
>  
> 
>  
> I am getting following exception gets thrown in FOP 2.0
>  
> 16:38:20.992 53425 [ReportFormatService-0] ERROR AreaTreeModel  - Error while 
> rendering page 1
> java.lang.RuntimeException: Error processing transparency channel:

Does not look like a FOP issue per se, but seems to point to either a bug or 
incomplete implementation in XGC's ImageLoaderRawPNG.

Difficult to say without the exact PNG that is used, but the class in XGC does 
contain a comment indicating that '...this image loader does not handle all 
kinds of PNG images...', so perhaps this is a known deficiency.

Have you tried giving the plain ImageLoaderPNG a higher precedence (= lower 
penalty value)?

If you are allowed to upload the PNG in question to Apache JIRA, do feel free 
to log an issue against XML Graphics Commons and attach it there, so the issue 
can be investigated.

HTH!

KR

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

Re: List exceeds page limits

[Andreas Delmelle]

Hi
> On 30 Oct 2015, at 17:57, Rahman USTA  wrote:
> 
> I have a long list in my document and list exceeds the page limits. How can I 
> solve this issue ?
> 
> Note: Attached a PDF output.

Can you attach the generated FO file, so that we can have a closer look? 

In case you don't know how to do that: 
Assuming you are already using FOP via the command-line, you can obtain this by 
using the -foout command line option instead of -pdf.


Thanks!

KR

Andreas

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

Re: Unable to Process Large Pragraph

[Andreas Delmelle]

> On Mon, Oct 19, 2015 at 4:22 PM, sripathi  wrote:
> Hi All,
> 
>  My document having a large paragraph(nearly 100 pages), FOP2.0 is unable to
> process this document.I know, i shouldn't give this much large para, but it
> is user requirement. Fop throwing OOM(Out Of Memory Exception), when it is
> calculating the breaking points for this large paragraph.

> Is there any XSL option is there to resolve this.

> On 19 Oct 2015, at 16:40, Luis Bernardo  wrote:
> 
> I assume you are putting a very large string inside a fo:block. Break the 
> string into pieces and put a  in between the pieces.
> 


What Luis said is the only viable fix for now. 
Another way to achieve the same, and which basically comes down to the same 
thing, but may be easier to implement, would be to insert forced linefeeds at 
certain places in the text. Make sure that the linefeed-treatment property is 
set to "preserve" on the fo:block.

At any rate, fixing this issue within FOP itself is definitely not something to 
expect in the short term, as it would require a rather invasive overhaul of the 
line/page breaking interaction.
 
HTH!

KR

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

Re: fop and stAX

[Andreas Delmelle]

 On 05 Jun 2015, at 23:07, robyp7 . rob...@gmail.com wrote:
 
 Hi to all,
 
 Can your Fop use Stax(pull) to handle events instead SAX (push)?

Short answer: Yes and no. :)

Expanded: 
Yes, it would be possible, if something were to happen.
No, it is not possible, unless something were to happen.

That something is the same in both cases: a rather invasive refactoring of 
the basics of FOP's processing model, which is at this point largely SAX driven.

That said, an interesting question.
Architecturally, what FOP currently does (for most output formats) could be 
construed as push-pull-push, IIUC. The semantic FO events are pushed by the 
SAX handler, and keep building up until there is an 
endElement('page-sequence'... event. At that point, a proprietary DOM structure 
has built up in memory.  
From there on, you could say that the content of the page-sequence tree is 
pulled up (recursive iteration), which leads to the LayoutManager tree being 
constructed, which in turn produces a tree of areas that can be pushed as XML 
events to any consumer / renderer.

It is conceivable to switch to StAX for the first step, and pull the events 
from the input FO directly, or offer an interface for a consumer to pull the 
area events in, but neither are tasks I would take too lightly.


KR

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

Re: hyphenation

[Andreas Delmelle]

Hi

 On 06 Jun 2015, at 09:46, Michał Jaworski mich...@beck.pl wrote:
 
 Hi,
 
 hyphenation jar (taken from offo page) was simply drop into lib dir. Fop is 
 called from the command line. Seems that works for en, doesn't work for pl. 
 My current example is very simple and attached at the end. The same example 
 processed under ver 1.1 works fine. As I've mentioned tried other fonts and 
 also built my own hyphenation jar using 2.0 sources.

I think I see a clue about the potential cause. I tried rendering your example, 
and hyphenation seemed to work properly, but then I noticed...

  fo:block font-family=Franklin Gothic Book font-size=20pt 
 line-height=1.0

I tried without using font auto-detection, so it was rendered in plain 
Helvetica, which obviously lacked a few glyphs, but did allow hyphenation to 
kick in and do its work.

Can you try this on your end? Just to see if it's related to the use of that 
custom font, as I suspect. 
There has been quite some work in the area of complex scripts, which may be 
playing a part here, but I am not entirely certain. If that is indeed the case, 
then a possible temporary workaround would be to disable those complex script 
features, see: http://xmlgraphics.apache.org/fop/2.0/complexscripts.html


Hope this helps!

KR

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

Re: hyphenation

[Andreas Delmelle]

 On 06 Jun 2015, at 20:22, Michał Jaworski mich...@beck.pl wrote:
 
 I tried Helvetica at the beginning and also other typical fonts. Disabling 
 scripts -nocs also is not solving this problem.
 

OK, thanks for checking. That can be ruled out then, at least.

 I've  just made funny observation. You can put as  @language whatever you 
 want and no exception is thrown! In 1.1 it was validated somehow and 
 @language=qq was visible on the console as an error in 2.0 case nothing 
 happens. Question if patterns are loaded at all.

This is getting really strange. I cannot reproduce that behaviour. I still get 
a log message like SEVERE: Couldn't find hyphenation pattern for lang=qq... 
?

Tested with a fresh fop-2.0 binary distribution. The error message appears both 
with and without the same fop-hyph.jar from offo placed in the lib folder.

Can you confirm that there is no interference from other installed versions, or 
something in that direction? That could happen, for example, if the location of 
an older fop script appears (earlier) in a PATH variable, and you are just 
running the script as fop ...

Try fop -version and verify that it really does show FOP Version 2.0.


KR

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

Re: hyphenation

[Andreas Delmelle]

 On 05 Jun 2015, at 18:22, Michał Jaworski mich...@beck.pl wrote:
 
 it's great that version 2.0 appeared after years. Question are there any 
 changes in hyphenation principles.

I don't think anything changed specifically in that area, but there may be 
other changes in play that have unintended side effects.

 We've been using version 1.1 after switching to 2.0 hyphenation is not 
 working for PL language at all (similar for EN using examples from binary 
 distribution).

Strange, I do not immediately see anything going wrong on my end... Given what 
you describe, my best guess would be that the pattern files are not loaded 
properly for some reason (?) 

Do you see any warnings in the console about pattern files not being found?

If not, can you provide more info? Do you just drop the hyphenation JAR in 
FOP's lib directory, or are you using the environment variable 
FOP_HYPHENATION_PATH, or ...?


Thanks!

KR

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

Re: FOP hyphenate-ladder-count and pre-hyphenated text

[Andreas Delmelle]

Correction (again… :-))

 On 08 May 2015, at 17:31, Andreas Delmelle andreas.delme...@telenet.be 
 wrote:
 
 snip /
 If you haven’t already found it, be sure to have a look at class 
 org.apache.fop.SerializeHyphPattern, …

Should be: org.apache.fop.hyphenation.SerializeHyphPattern



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

Re: FOP hyphenate-ladder-count and pre-hyphenated text

[Andreas Delmelle]

 On 08 May 2015, at 08:59, Marc Wiest marc.wi...@getabstract.com wrote:
 
 Seems like some refactoring may be in order here, to streamline and better 
 merge the two approaches.
 @Marc: Will you log a request for enhancement in JIRA for this, or shall I?
 
 @Andreas: thank you very much for that thorough feedback and insight into how 
 it all works. It's the way I suspected it to be :( I would appreciate you 
 making the request, because you, for sure, can articulate the problem more 
 accurately and precisely than I ever could.

OK, will do.

snip /
 
 I'll see if I find the time to pull the source code and see if I can fix 
 problem 1. myself (being able to add hyphenation exception to the actual FOP 
 hyphenation system at runtime) and send a pull request - if I manage to find 
 a solution that seems to be general enough to serve other people, too.
 My idea would be to
 1. Create or find a public Java-method for building .hyp files from (updated) 
 .xml hyphenation patterns - containing the exceptions, so this could be done 
 on-the-fly. As I understand, this is now part of the build process of FOP.

If you haven’t already found it, be sure to have a look at class 
org.apache.fop.SerializeHyphPattern, which is used for that purpose during the 
build process. The class is part of the regular source tree, so should be easy 
to locate.

Be aware though, that since this file is normally used during the build 
process, there are no guarantees that it is safe and fit for use in a web 
container context… If you experience issues in your attempts, be sure to post 
to fop-dev@.


Hope this helps!

KR

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

Re: FOP hyphenate-ladder-count and pre-hyphenated text

[Andreas Delmelle]

Hi Marc

 On 06 May 2015, at 13:40, Marc Wiest marc.wi...@getabstract.com wrote:
 
 I have the requirements of
 1. allow adding hyphenation exceptions at runtime (web container)
 2. don't hyphenate more than two successive lines in a paragraph
 
 For 1. the only solution I found is to use a third-party library to add the 
 actual soft-hyphens in the text, instead.
 This has other benefits for me, including that I can use hyphenation in other 
 places than PDF generation, so I prefer this separation.
 But if anyone knows a way to add exceptions for words at runtime, I would be 
 highly interested how to do that.
 
 Since I solved 1. Using a new library for adding soft-hyphens into the text, 
 2. doesn't work anymore. My XSL contains hyphenation-ladder-count=2 
 attributes on all relevant blocks, which does the trick when passing text 
 without soft-hyphens and relying on FOP hyphenation entirely. But it does 
 nothing if I don't use FOP to hyphenate the words. In general, hyphenation 
 works, though, like the soft-hyphens in the text are taken into account. But 
 it happens that 6 or more successive lines are hyphenated, which is deemed 
 bad style.

The effect you see in FOP is just very basic Unicode line breaking at work. 
An explicit SHY is obviously a legal breaking point, but is not recognised as a 
true hyphenation point by FOP. 
Internally, what FOP tries to hyphenate are only the word fragments in between 
the spaces and SHYs, but those cannot be broken up further themselves. As 
strange as it sounds, a SHY is treated as a word boundary here, similar to a 
zero-width space.
The SHY is recognised as a special character, however, that only needs to be 
taken into account and rendered in case the effective line-break occurs at that 
point, but that is as far as it goes, currently.

Not sure how difficult it would be to make FOP recognise that the text in a 
paragraph has already been hyphenated and then register the SHY as a 
precomputed hyphenation point. If that can be done, then 
hyphenation-ladder-count would 'automagically' come into play here.

At any rate, something like the above would be a prerequisite for adding 
hyphenation exceptions. As long as FOP does not see a SHY as a hyphenation 
point, it is almost useless to add exceptions on this end.


KR

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

Re: FOP hyphenate-ladder-count and pre-hyphenated text

[Andreas Delmelle]

snip /
 Internally, what FOP tries to hyphenate are only the word fragments in 
 between the spaces and SHYs, but those cannot be broken up further 
 themselves. As strange as it sounds, a SHY is treated as a word boundary 
 here, similar to a zero-width space.

Correction/Expansion: 
ZWSP is actually a bad analogy, and quite differently treated by the Unicode 
algorithm, since the character *is* the break opportunity (=break *on* or 
*before*).
With SHY, the break opportunity lies *after* the character.

Still, internally for FOP, the result is roughly the same. The accumulated 
sequence of characters since the previous break opportunity is taken to be a 
'word', which may or may not end in a hyphen. If the latter is true, a specific 
sequence of elements is glued to the word-box, to prevent a break before SHY 
and make sure that it is properly rendered, i.e. only counts if the break 
occurs right after.

As hyphenation by FOP itself is applied at a higher level, when all layout 
elements for a whole paragraph have been collected, that SHY sequence is seen 
as a word boundary. That is, that part of the algorithm just accumulates the 
text for ‘uninterrupted' sequences of word-boxes, and feeds those pieces to the 
hyphenator. The real intention is to apply hyphenation across any nested 
fo:inlines. ‘Uninterrupted’ means that auxiliary elements, generated for border 
or padding are explicitly *not* considered as word boundaries. The sequence 
generated for SHY contains two non-auxiliary elements, as if it were a space. 
Perhaps, just to ensure that that position in the layout always leads to a 
character that is visibly rendered.

In case of pre-hyphenated text, this has the unintended effect of restricting 
the input for the hyphenator to parts of words, which is basically meaningless 
(and wasteful).

BTW, there is an entry related to rendering of SHY logged in JIRA already, but 
more specifically about copy-paste functionality: 
https://issues.apache.org/jira/browse/FOP-2358

Seems like some refactoring may be in order here, to streamline and better 
merge the two approaches.

@Marc: Will you log a request for enhancement in JIRA for this, or shall I?


KR

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

Re: fop listener

[Andreas Delmelle]

On 22 Mar 2011, at 16:20, Roberto Cahanap wrote:

Hi Roberto

 Is there a way to run FOP as a listener to a certain port? I was told that 
 this was possible with FOP.

It is definitely /possible/, just as any other Java program, but not 
out-of-box, i.e. it will take /some/ extra development effort and is not just a 
matter of passing a command-line switch, if that is what you're looking for...

If you're already familiar with servlet programming, you can opt to deploy it 
in a servlet container: a sample FOPServlet is included in the distro (but do 
note that this is not at all complete and secure!)

Another way to handle this is to write your own small Java wrapper, which 
prepares a socket and listens on a port of your choosing. Just set up a 
sleeping thread in an infinite while-loop, and have it wake up when a request 
comes in. Programming sockets and threads in Java is almost child's play. 
Obviously, you then have to safeguard that service against potential DoS 
attacks, especially if it is exposed to the outside. At any rate, you would 
definitely not have to reinvent the light-bulb here, as it can be based on your 
average sample java.net demo program.


Regards,

Andreas
---


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

RE: Row span and keep-togehther.within-page problem

[Andreas Delmelle]

Hi Mathias

 -Original Message-
 From: Matthias Reischenbacher [mailto:matthias8...@gmx.at] 

 thanks for your reply. I'm not quite sure if your mentioned bugzilla entry
 is really related because I'm not using fixed row heights. Perhaps Vincent
 can shed some light on this. I'd be interested in knowing how a keep
 condition is enforced in general (using Non-break Knuth elements?) ...

The basics are pretty straightforward, especially for a keep-constraint with 
strength of always.

In the Knuth model, a box is /never/ a legal breakpoint, so to enforce a keep 
between two boxes, nothing special needs to happen. Two consecutive boxes will 
always be kept together, no matter what.
A penalty, on the other hand, is always a legal breakpoint /unless/ it has 
value infinite, in which case it prevents a break from occurring.
Lastly, a glue is only a legal breakpoint if it is preceded by a box. So, to 
keep a glue together with a preceding box, we need to insert an infinite 
penalty to prevent the break.

If I recall correctly, integer keep-values still behave roughly similar to 
always, as it is non-trivial to discourage a break purely by means of 
auxiliary elements. Inserting a non-infinite penalty, even with an insanely 
high value, still generates a break-possibility that may be selected by the 
algorithm contrary to what one would expect (e.g. when there are regular 
box-glue combinations or other penalties with a lower value nearby).

 and where the probable cause lies (missing break elements or incorrect break
 algorithm?).

As Vincent already indicated, the issue is likely located in the table-layout 
code, more precisely the element-list generation. However, it may simply point 
to a limitation in our implementation of page- and column-keeps...
Since the keep is defined as a keep.within-page, a zero penalty is used, since 
strictly speaking, a column-break is still permitted.

That said, I think you may be able to work around the issue by specifying it as 
keep-together.within-column=always, if that fits the use-case.


HTH!

Regards,

Andreas
---


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

Re: Row span and keep-togehther.within-page problem

[Andreas Delmelle]

On 18 Mar 2011, at 00:30, Matthias Reischenbacher wrote:

 snip /

FWIW: I was just playing with the example, and noticed my suggestion --using 
keep.within-column-- does not help.

This means, as Vincent suspects (IIC), that the culprit is the code that takes 
care of generating the element list in case of row-spanning cells, which 
inadvertently generates break-possibilities (i.e. does not take into account 
the keep that is dominating the ancestor fo:table)

Comparing the case with and without row-span in a debug session reveals that, 
with row-span all BreakElements have penalty value 0, whereas without row-span, 
we get INFINITE, as expected.

Looking deeper, in TableContentLM.getKnuthElementsForRowIterator(), notice that 
the case with row-span produces only one row-group, so the code that would set 
the keep constraint from the table --in the while loop, line 250-- never gets 
executed. The RowGroupLayoutManager gets passed a LayoutContext that is not 
properly initialized (keep=auto).


Regards,

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

Re: Wrap text

[Andreas Delmelle]

On 15 Mar 2011, at 17:00, pedro wrote:

Hi Pedro

i have a document with some column.One of this column have a string that
 is to large for the column and then override the text of the next column.How
 i can wrap the text?

FOP implements Unicode UAX#14 line-breaking, which does not allow a break 
between regular alphabetic characters.
The suggested workaround is to inject ZWSP (U+200B) into the text, either at 
carefully chosen positions or between every two characters.
The main message is to give FOP a chance to break the content, without 
violating Unicode line-breaking rules.

Hope this helps!

Regards,

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

Re: PDF version specification

[Andreas Delmelle]

On 14 Mar 2011, at 19:09, Glenn Adams wrote:

 I've been working in the background on a patch that adds support for using 
 newer PDF features, including page transitions and option groups, and in this 
 work defined an new element in the FOP CONF file as follows to specify the 
 PDF output version:

Heh... Sounds interesting, and reminds me of something I once started, way back 
when: see Bugzilla 45390. The idea of using generic dictionary objects was 
already there, but only as an extension to the document trailer, offering the 
possibility of specifying some viewer/print options (e.g. default zoom, page 
scaling, JavaScript onLaunch action...)

Never got around to finishing it, though :-(



Regards,

Andreas
---


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

Re: Flow data in 2 different regions?

[Andreas Delmelle]

On 14 Mar 2011, at 20:09, Eric Douglas wrote:

Hi Eric

 I use the position=absolute attribute.
 With that there are attributes for left, top, width, and height.
 I set them all but they may be optional.  If you just leave out height
 does it spill to the next page?  

Nope. :-(

If height=auto, and the content grows sufficiently large, absolute-positioned 
block-containers will eventually cause overflow at the relevant edge of the 
page (or more precisely: whatever area they are 'absolutely' positioned in), 
but will never trigger a page-break themselves. I guess you could see it as 
kind of a static-content, but then, not repeated.

 If not, that could get complicated trying to wrap text to a new page.

Indeed. You would basically have to precompute and force all the breaks 
yourself, instead of leaving that up to FOP. :-/


Regards,

Andreas
---


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

Re: FOP 1.0 PDF print scale problem

[Andreas Delmelle]

On 03 Mar 2011, at 11:11, Marc Kramis wrote:

Hi Mark

 We recently migrated from FOP 0.95 to FOP 1.0. Everything worked fine except 
 some strange problem with the Mac OS X 10.6.6 print preview dialog. This 
 dialog now consistently wants to scale the printed PDF down to 90%.

By any chance, do you mean the print preview dialog of the Preview application?

If yes, it might be influenced by the 'Initial Document Scale' and 'Define 100% 
scale as' settings in Preview's Preferences.


Regards,

Andreas
---


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

Re: fo:block and fo:inline: less space?

[Andreas Delmelle]

On 23 Feb 2011, at 09:22, li...@philipp-wagner.com wrote:

Hi Philipp

 I'm having a little FO problem. It's not really FOP specific, the output 
 looks pretty much the same with XEP, but here it goes:
 
 I have an auto-generated document that has a lot of
 fo:blockfo:inlinesome text/fo:inline/fo:block
 
 For bigger font sizes (e.g. 12pt) the fo:inline does not have much of a 
 visible impact (it looks almost or completely the same with or without the 
 nested fo:inline).
 
 But if I use smaller font sizes (7pt), I get big spaces between two following 
 fo:blocks.

IIC, the effect you are seeing is due to the difference in font-size between 
the inline and the block. Line-height defaults 120% the font-size, IIRC, so 
font-size=12pt means an implicit line-height=14.4pt.

The only way I know of to mitigate the effect you're seeing, is to make sure 
the smaller font-size/line-height are specified on the surrounding fo:block, 
from which they will be inherited by the fo:inline anyway.


Regards,

Andreas
---


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

Re: fo:basic-link show-destination=new status

[Andreas Delmelle]

On 21 Feb 2011, at 16:25, Jeremias Maerki wrote:

Hi

 Is this issue is still there or it is fixed in FOP 1.0 version? 
 If so, what I can do at my side?

In addition to what Jeremias mentioned, I also remember from when implementing 
this, that the Adobe browser plugin does not respect the corresponding PDF flag.
See also the remark on the compliance page:
http://xmlgraphics.apache.org/fop/compliance.html#fo-property-show-destination

Try following the same external link after opening the PDF in the standalone 
Adobe Reader, and it should open a new Adobe Reader window. From within the 
browser, no such luck, but this seems like an issue with the plugin. Not 
something that FOP can solve...


Regards,

Andreas
---


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

Re: How Shall I change the Log Level

[Andreas Delmelle]

On 14 Feb 2011, at 11:48, Clement Jebakumar (RBEI/EMT2) wrote:

Hi Clement,

 How to change the log level from Java? Am using Example DOM to PDF 
 conversion. I like to get see the logs of level Trace. How to set up?

FOP uses Apache Commons Logging, so the most complete information can be found 
in its documentation:
http://commons.apache.org/logging/commons-logging-1.1.1/guide.html

Hope this helps!


Regards,

Andreas
---


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

Re: PDF output: fragment identifier working ?

[Andreas Delmelle]

On 14 Feb 2011, at 08:42, kuma wrote:

Hi

 I am having this problem where I am generating a pdf file with links to 
 specific 
 pages of another pdf file using Java FOP. Somehow when i click on the link 
 rather than going to that page(lets say page=3), it goes to the next higher 
 page(say page 4). 
snip /
 
 Here is the code(not the whole code, but related to the page linking issue) 
 in 
 my .xsl:

Sorry, but in order to be able to judge whether this is a FOP issue, we need to 
see the *FO*. That is, the result of applying this XSL code to the input XML.

Have you verified that the generated link actually points to the correct page?


Regards,

Andreas
---


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

Re: Problem running FOP on VMS

[Andreas Delmelle]

On 08 Feb 2011, at 17:19, Jonathan Levinson wrote:

Hi Jonathan

 Thanks for the help!  We are not running Eclipse or SWT.
 
 Here is a fuller log of the exception.  Can you see anything wrong with what 
 we are dong?  Thanks!

It doesn't seem like you're doing anything wrong from a FOP perspective.
Consider that an UnsatisfiedLinkError means that the Java VM cannot locate the 
native-language definition of a method that was declared 'native' in the source.

As FOP itself does not define any native methods, and AFAIK, it does not call 
any native methods either (not sure if AWT even exposes these in the public 
API), the issue seems to be located in the Open VMS AWT implementation.

One thing to try to get a more accurate picture of which call in FOP ultimately 
triggers the issue in Open VMS, you could try setting the log level to TRACE or 
DEBUG. Right now, with INFO level, we can only see that it happens right after 
the default page-dimensions have been set from the user-config. That leaves 
font- and image-setup, but one could tell that solely from the fact that it's 
AWT-related...


Regards,

Andreas
---


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

Re: XML data with HTML tags, and creating PDF file

[Andreas Delmelle]

On 09 Feb 2011, at 06:26, Ashish Kulkarni wrote:

Hi

This is actually strictly an XSLT-related question. This list is dedicated to 
questions about FOP usage (= converting FO to another output format using FOP). 
Please try to keep that in mind for future posts. Thanks!

Now that that's out of the way:

 I have an XML document as below, i am using FOP to create PDF file, i am 
 hoping to translate those HTML tags in my output, for example i want some 
 text bold in my PDF file, so if the XML file has
 
 para4
  My Data, this i want italic
![CDATA[this is my node. ithis is italics/i this is bbold/b]]
 /para4
 and in style sheet i have
 
 fo:block text-align=left 
   xsl:value-of select=para4 disable-output-escaping=no /xsl:value-of
 /fo:block

That (disable-output-escaping) is best not used. It is deprecated in XSLT 2.0, 
and in XSLT 1.0, strictly speaking, processors are not mandated to support this.

Besides that, using the above construct will yield FO with intermingled HTML 
markup like:

fo:blockthis is my node. ithis is italics/i this is bbold/b/fo:block

FOP is not designed to interpret HTML, only the FO part. In your case, the 
processor supports d-o-e, so the 'i' and 'b' elements are reported by the 
parser, but FOP does not know what to do with them, so just handles the text.

In order to convert that to proper FO (= markup that FOP knows how to 
interpret):
1. First, you will need to make sure the ![CDATA[...]] markup in the source 
file is eliminated, so that you just get plain XHTML markup. I.e. you do *not* 
want the lexical equivalent of

...this is my node. lt;ithis is italicslt;/i this is lt;bboldlt;/b...

You need the 'i' and 'b' elements to be reported to the XSLT processor as 
elements.

2. Once that is done, you can write simple XSLT templates to translate the 
XHTML markup to FO markup, like so:

xsl:template match=i
  fo:wrapper font-style=italicxsl:value-of select=. //fo:wrapper
/xsl:template

and further on, when building the fo:block, using apply-templates will trigger 
the built-in template rule for the text() nodes, and the use of the above 
template to handle the 'i' element node:

fo:blockxsl:apply-templates select=para4 //fo:block



Regards,

Andreas
---


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

Re: AFP Rendering

[Andreas Delmelle]

On 05 Feb 2011, at 10:24, Sandeep Dhulia wrote:

Hi Sandeep

 I downloaded the nightly build, but I get following error when I run my 
 solution with it
  
 java.lang.NoSuchMethodError: 
 org.apache.xmlgraphics.util.Service.providerNames(Ljava/lang/Class;)Ljava/util/Iterator
  
 Am I missing anything here?

I suspect that you still have an older version of the XMLGraphics jar somewhere 
in your classpath. That particular method was added about a month ago.


Regards,

Andreas
---


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

Re: AFP Rendering

[Andreas Delmelle]

On 05 Feb 2011, at 19:57, Andreas Delmelle wrote:

... and for the sake of completeness, here's a quick link to download the 
latest XGC binary from FOP's trunk:
https://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.5svn.jar?view=co


Regards

Andreas
---
 On 05 Feb 2011, at 10:24, Sandeep Dhulia wrote:
 
 Hi Sandeep
 
 I downloaded the nightly build, but I get following error when I run my 
 solution with it
 
 java.lang.NoSuchMethodError: 
 org.apache.xmlgraphics.util.Service.providerNames(Ljava/lang/Class;)Ljava/util/Iterator
 
 Am I missing anything here?
 
 I suspect that you still have an older version of the XMLGraphics jar 
 somewhere in your classpath. That particular method was added about a month 
 ago.
 
 
 Regards,
 
 Andreas
 ---
 
 
 -
 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 create a border against row

[Andreas Delmelle]

On 04 Feb 2011, at 21:55, Ashish Kulkarni wrote:

Hi

 I need to create a border against one row as shown in screen below, the sides 
 dont need to be dotted, but solid
 
 Here is what i have 
 
 fo:table width=20cm table-layout=fixed

What about just using

fo:table width=20cm table-layout=fixed border=solid 1pt black

?


Regards,

Andreas
---


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

Re: Data URI handling by fox:external-document

[Andreas Delmelle]

On 03 Feb 2011, at 18:14, Malcolm Murphy wrote:

Hi Malcolm

 Questions:
 Is this the correct behaviour? Or do I have an environmental problem?

No and no. It does not seem like correct behavior, and at this point, I do not 
suspect an issue in your environment.

 If its not correct
 
 1) Can the external-document element take a Data URI as the src
 parameter by some simple change?

That I cannot immediately judge. However, it definitely does not seem like this 
possibility was taken into account when developing the extension.

 2) More generally it possible to have the two elements handle the uri
 resolution in the same way?

Ideally, that should be the case. This I could already trace down. The code 
that constructs the image from the URI in the case of fo:external-graphic 
strips off the url() function call before handing the URI over to the 
ImageManager, while fox:external-document passes the specified value, untreated.

The fix for part 2) is a simple modification that affects one line of code. 
org.apache.fop.layoutmgr.ExternalDocumentLayoutManager, line 95, should become:

String uri = URISpecification.getURL(getExternalDocument().getSrc());

That should fix the cases:
fox:external-document content-type=pdf src=url('...')/

Part 1) I am not 100% sure of. Judging from the code in 
ExternalDocumentLayoutManager, I would say some modifications may be necessary 
there to cater for the possibility of a Data URI as well.


Regards,

Andreas
---


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

Re: Font detection on a Character by Character basis

[Andreas Delmelle]

On 03 Feb 2011, at 21:26, Graeme Kidd wrote:

Hi Graeme

 
 If adapting FOP to detect Fonts on a character by character basis is not 
 advisable then I will look into your suggestion of recursive templates on the 
 text() nodes or if that slows things down too far I will just have to move 
 onto SAXON.

On the one hand, it should prove relatively straightforward to adapt FOP to 
switch to generating separate boxes for each character in a given font, 
depending on the value of the font-selection-strategy property. The property is 
already parsed and bound to the FOs, so all that really needs to be changed is 
org.apache.fop.layoutmgr.inline.TextLayoutManager, mainly 
getNextKnuthElements(). It seems conceivable to check if the current character 
can be rendered in the same font as the previous one, and if not, terminate the 
word-fragment and start a new one. We would then end up with three consecutive 
boxes in the example, whereas currently, we only generate one.

On the other hand, there is currently still an issue that may prove harder to 
solve, even with the word-by-word selection. The issue is the alignment of the 
glyphs in the different fonts. You can check this for yourself if, instead of 
using fo:inline, you would insert word-joiners (U+2060) in between the 
characters. That will force FOP to treat each character as its own 'word', and 
select the correct font for each.
You will then notice that the Symbol glyph appears much too low in comparison 
to the Helvetica glyphs. This issue is mitigated if you use fo:inlines, since 
those establish their own alignment-context.


Regards,

Andreas
---


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

Re: Font detection on a Character by Character basis

[Andreas Delmelle]

On 03 Feb 2011, at 20:38, Graeme Kidd wrote:

 Just noticed that FOP detects what font is needed based on the first letter 
 of the word.
snip /

BTW, note that this is not entirely correct. FOP selects the font that can 
render most of the characters. If you were to make it N⇒⇒⇒Y, you would see 
#⇒⇒⇒#


Regards,

Andreas
---


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

Re: Concurrent modification exception getting an instance of ICC_Profile

[Andreas Delmelle]

On 31 Jan 2011, at 10:38, Julien Aymé wrote:

Hi Alexios, Julien,

 2011/1/31 Alexios Giotis alex.gio...@gmail.com:

 Any ideas why calling java.awt.color.ICC_Profile.getInstance() throws 
 java.util.ConcurrentModificationException ?

 It seems that you just found out a race condition in
 ProfileDeferralMgr.
snip /

I don't think it was meant for concurrent usage, but could be wrong. I was 
always under the impression that AWT expects the calling code to synchronize 
wherever appropriate. We have noticed similar issues in the past, with the AWT 
font-related classes.
AFAIK, AWT makes no claim whatsoever about being thread-safe, so the issue 
should be fixed on our end. 

 It seems that a similar issue was encountered an fixed in Fop 0.95:
 http://www.mail-archive.com/fop-dev@xmlgraphics.apache.org/msg11808.html
 
 Maybe we should check where ICC_Profile.getInstance is used on FOP
 codebase and synchronize this method (sync on ICC_Profile.class ?)

IIC, the issue here arises from within XMLGraphics. There are, however, still 
two distinct places in FOP's code that can trigger the issue 
(ColorSpaceCache.getString() and PDFRenderingUtil.addDefaultOutputProfile()). 
Those, I have taken care of in the patch attached to Bugzilla 50698 
(https://issues.apache.org/bugzilla/show_bug.cgi?id=50698), which will likely 
find its way into Trunk soon.

A similar fix would still need to make it into XMLGraphics in order to avoid 
the race condition in this particular case.


Regards

Andreas
---


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

Re: pdf encryption

[Andreas Delmelle]

On 31 Jan 2011, at 15:49, sabac wrote:

Hi

 snip /
 when i write on the password positions 'null', why they ask for a password?
 can i set the encryption params without the password params? is there a
 different possibility?

If I recall correctly, older versions of Adobe Reader exhibited the same 
behavior, and it was due to FOP generating two /ID entries in the PDF Document 
trailer in case encryption was used.
Can you try to regenerate the PDF using FOP 1.0, and see if it persists? The 
issue should be fixed there.


Regards,

Andreas
---


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

Re: align columns last line

[Andreas Delmelle]

On 28 Jan 2011, at 17:05, Rob Sargent wrote:

Hi Rob

 The distribute attribute definitely improves the output, but indeed
 there are situations in which it fails to align the columns.

 I'm not a stranger to space-before but I didn't know about the
 sub-attributes.  I'll give those a try, but it will likely be some time
 next week before I can report my findings. The distribute attribute
 apparently adjusts leading between lines within paragraphs.  Would it be
 correct to assume using space-before.* would shift whole blocks?.

Yes. 

Vincent is correct btw, in that the dependency on a proprietary extension 
should be avoided as much as possible, especially given that it is undocumented.
Nevertheless, the described alternative does have the downside that it will do 
no good if a block is big enough. If there is no more room to fit the next 
header into the same column with the minimum space-before, elastic space-before 
or space-after will not solve the issue. You will be left with an 'underfull' 
column. The line-spacing within a paragraph will still remain the same 
throughout the document.
The standard alternative would be to specify 'line-height' in a similar manner. 
The property accepts values similar to space-*, so in theory you could do:

fo:block line-height.minimum=1.2em line-height.maximum=1.6em

which would allow the formatter to choose the optimal line-height somewhere in 
between 1.2 and 1.6em.

I was not sure whether FOP supported it, but I just tried it with a smaller 
test document, and it did seem to have some effect, so you might want to look 
into that as well.


HTH!

Regards,

Andreas
---


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

Re: align columns last line

[Andreas Delmelle]

On 27 Jan 2011, at 16:35, Rob Sargent wrote:

 Here is the fo.  (But the last time I did this it was not well
 recieved.)  
 I'm not confident I could crop it significantly and still
 have a useful fo.

OK, I see what you mean now.
Did you try out Jeremias' last suggestion? If I just put 
display-align=distribute on every region-body, the result has top/bottom 
edges far better aligned, although you then do get pages where there's slightly 
more space between the lines in one column compared to the other.


Regards,

Andreas
---


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

Re: align columns last line

[Andreas Delmelle]

On 27 Jan 2011, at 20:25, Rob Sargent wrote:

 I will most certainly give that a try, even if
 http://www.w3.org/TR/xsl/#display-align does not suggest that is a valid
 doesn't suggest that as an option.  

Indeed. That is because, as Jeremias explained, it is a non-standard (= 
FOP-proprietary) extension.

 I guess I need a better reference for the current state of fop.

Well, this particular extension is documented nowhere, AFAIK. 
Reason is that, so far, no one has put any effort in verifying the behavior, so 
we are not confident enough to advertise it as part of FOP's core 
functionality...



Regards

Andreas
---


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

Re: align columns last line

[Andreas Delmelle]

On 26 Jan 2011, at 19:42, Rob Sargent wrote:

Hi Rob,

 Is there really no fop way to get consistently placed top and bottom
 lines, such as one expects in a multi-column page of a magazine?

No mechanism defined for this in standard XSL-FO 1.1, unfortunately...

 I can see that this would mean reverse-leading(?) after the contents of
 the page had been established, but it seems a fundamental formatting
 requirement.

IIRC, FOP does take care of column-balancing, but only does so for all but the 
last page. More or less similar to a line-layout, where you generally apply 
alignment justification on all lines but the last.

One possible way out could be to put in a trailing, empty fo:block with 
span=all set. That should trigger column-balancing, even if the content takes 
up less than one page. In combination with display-align=center, that might 
come very close to what you're looking for. If I understand the requirement 
correctly, that is...

Hope this helps.

Regards,

Andreas
---


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

Re: align columns last line

[Andreas Delmelle]

On 26 Jan 2011, at 23:44, Rob Sargent wrote:

 On 01/26/2011 12:02 PM, Andreas Delmelle wrote:
 IIRC, FOP does take care of column-balancing, but only does so for all but 
 the last page. More or less similar to a line-layout, where you generally 
 apply alignment justification on all lines but the last.
 
 
 Hoping that the notion of balancing isn't just to approximate equalize
 the vertical length of the columns...

Hmm, that is precisely it, I'm afraid, and it is enabled by default. The 
extension property is prefixed 'disable-' precisely because it alters FOP's 
standard behavior. Column-balancing doesn't work as expected in some scenarios, 
mainly in combination with footnotes, but for not-too-complex use cases, it 
should suffice.

I thought you were referring to unbalanced columns within the same page, which 
can happen on the last page. The other pages should already be balanced. I must 
have misunderstood the issue...?


Regards,

Andreas
---


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

Re: align columns last line

[Andreas Delmelle]

On 27 Jan 2011, at 01:03, Rob Sargent wrote:

 We see much variability in the y-coordinate of the last lines both
 with-in and across (facing) pages.  There are cases where keep-with-next
 causes obvious shortages in one column.  

Ah OK, you're using keeps... I can see how that could be a deal-breaker when it 
comes to column-balancing.

 To be fair some of these gaps
 would be too large to rectify by simple adding space between the lines
 and we will deal with these at the authoring level.  But we see many
 cases of routine paragraphs split at varying distances from the bottom. 
 Others see perfectly matched bottom lines? Are there other factors which
 might be getting in the way?

Difficult to tell without seeing the source. 
Is it possible to post the FO, or a smaller excerpt exhibiting the described 
behavior, so that we can have a closer look?


Regards,

Andreas
---


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

Re: AW: AW: AW: [FOP 1.0] Worse performance than with 0.20.5 !?

[Andreas Delmelle]

On 24 Jan 2011, at 10:50, Georg Datterl wrote:

Hi Georg

 There's a patch around, which never got applied to fop. This patch frees 
 memory even in page sequences. Maybe that patch can help.

Thanks for the pointer! For future reference, the patch is stored as an 
attachment in Bugzilla 47314.

As I read/understand it, it doesn't really free up the memory /in/ 
page-sequences, but rather, it enables you to break up a document in multiple 
page-sequences and omit the implicit page-break in between.

It could be helpful in this case, but I'd have to study the patch closer to see 
if it can be applied. What happens if one of the page-sequences has an 
initial-page-number set for example. In that case, I would expect the new code 
to have no effect, unless that initial page number happens to match the last 
page in the previous sequence... Details like that.



Regards,

Andreas
---


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

Re: NullPointerException in layoutmgr.AbstractBreaker.getNextBlockListChangedIPD

[Andreas Delmelle]

Hi Graeme,

 The attached FO stylesheet creates the following NullPointerException:
 
 java.lang.NullPointerException
 at 
 org.apache.fop.layoutmgr.AbstractBreaker.getNextBlockListChangedIPD(AbstractBreaker.java:815)
 at 
 org.apache.fop.layoutmgr.AbstractBreaker.doLayout(AbstractBreaker.java:428)
snip /
 
 Shall I go ahead and submit this as a bug? If so I can also try and develop a 
 test case as well.

Yes, please. As for the test case, I think the attached FO is enough. 
Or did you have something else in mind?


Thanks!


Regards,

Andreas
---


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

Re: AW: AW: [FOP 1.0] Worse performance than with 0.20.5 !?

[Andreas Delmelle]

On 21 Jan 2011, at 08:31, Matthias Müller wrote:

Hi Mathias

 I temporarily disabled all images and special fonts in my fo file and still 
 have 
 the issue with the heap space. So i assume that i only have a chance to 
 improve 
 the rendering by splitting the document in multiple page-sequences. The thing 
 is 
 now, that the size of the single tables may vary extremely. There's also a 
 case 
 that i produce a table over 400+ pages !!!
 What about splitting the tables after each, let's say, 20 pages? Where's the 
 best performance, less than 20?

That could be a good start, but --it depends. It's really very difficult to say 
how many pages is ideal.
It is possible to let FOP run out of heap space with a document containing only 
a single fo:block with a dump of a chapter generating about 40 pages (or even 
only 1 page --at font-size 1pt). That is, purely the layout engine's 
linebreaking algorithm. No fancy fonts or tons of images. Not even a fo:table. 
On the one hand, that admittedly points to a lack of scalability.
On the other, the fact remains: divide and conquer. Breaking up that same 
fo:block into multiple blocks can make a world of difference.

For the end-result, it is obviously best to break the content at a boundary 
that makes sense logically. You can try to approximate how many rows you can 
fit into one page, and try to insert breaks from there, but that will likely 
lead to results that make little sense to the ultimate consumer/reader of the 
document...

 
 I almost forgot the most important point: If I split the table after the 20th 
 page (or rather: after each 200th table rows (assuming ~10 rows per page)), 
 how 
 do I ensure that the page-sequence ends at the page bottom. The size of the 
 rows 
 also may vary.

Short answer: you can't. Splitting into multiple fo:page-sequences is always a 
trade-off, since it introduces a forced break that is basically arbitrary, 
unless you can /make/ it so that the break makes sense there.

Longer anwser is that one might be able to pull it off, but that would require 
a two-pass approach. In your case, that seems non-applicable, since the first 
pass will cause the out-of-memory condition.



Regards

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

Re: AW: [FOP 1.0] Worse performance than with 0.20.5 !?

[Andreas Delmelle]

On 18 Jan 2011, at 12:07, Matthias Müller wrote:

Hi Mathias

 indeed, in the document I only have one page-sequence over 500+ pages.
 There are approx. 10 tables that stretch about 1 - 150 pages each.
 There are also nested tables.
 There are 3 images ( 30kb) on each page's footer.
 Your idea is to rewrite the stylesheets that each table is enclosed by a 
 separate page-sequence. Am I right?

That would be the most important change, indeed, but that would only be 
possible if there is no requirement to keep them together (i.e. to create pages 
containing the last rows of one table plus some rows of the next). 
If it is OK to have each table start on a new page, splitting into multiple 
page-sequences is definitely the first thing that I would try.

Your images, I think, do not contribute to the memory usage. I assume they are 
fo:external-graphics, so they would be cached by URI, and there should normally 
be only one instance for each distinct image in the document.


Regards

Andreas
---


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

Re: [FOP 1.0] Worse performance than with 0.20.5 !?

[Andreas Delmelle]

On 17 Jan 2011, at 09:09, Matthias Müller wrote:

Hi Mathias

 i finally updated my stylesheets for Fop 1.0 compliance. Now i run into java 
 heap space errors when rendering large documents (500+ pages, nested tables). 
 The thing is: with Fop 0.20.5 it works.
 It seems that Fop 1.0 needs more memory than its predecessor. Are there any 
 tweaks? I set the -Xms and -Xmx options to its maximum (1200m).

How much memory FOP 1.0 uses depends heavily on the FO structure. 
Are you trying to render one fo:page-sequence of 500+ pages, containing a lot 
of nested tables? 
If so, then it can very well be that 1.0 is more memory-hungry than 0.20.5. 
If the 500+ pages are neatly distributed over page-sequences of around 20 
pages, the matter becomes quite different.

On the other hand, one also needs to take into account the fact that 1.0 
implements more features. Extra functionality requires extra resources, 
obviously, so I would expect /some/ difference.

FWIW: I did a similar test myself once, and a document that required +1GB heap 
on 0.20.5 took 'only' 640MB of heap on 1.0 (well, actually 0.94 at the time).

Are there any other specifics you can give us about the document? (e.g. lots of 
fo:instream-foreign-objects or other images, forward references to pages 
towards the end of the document...)

If it is possible and it contains no confidential information, you can send me 
the FO source off-list, and I will have a closer look to see what the options 
are, if any, to bring the required amount of memory down. 


Regards,

Andreas
---


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

Re: Embedding SVG dynamically into fo file

[Andreas Delmelle]

On 17 Jan 2011, at 16:56, Cristi Cioriia wrote:
 
Hi Cristi

 Thanks for such a quick reply.
 
 Using your feedback I was able to advance a little: if I replace  Some text 
  from your sample with xsl:value-of select=svg/ I can see in my report 
 the svg that is generated. What I need though is that this code is executed 
 so that in the PDF report I have the actual image, not its SVG 
 representation. Any hint on how can I achieve that?

Do you mean that the svg node in the source document contains the actual SVG?

In that case, I think you should be able to do something like:

xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xmlns:fo=http://www.w3.org/1999/XSL/Format;
xmlns:svg=http://www.w3.org/2000/svg;
...
fo:instream-foreign-object
  xsl:copy-of select=svg/svg:* /
/fo:instream-foreign-object


Regards,

Andreas
---


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

Re: Rendering differences: fop-0.95 vs fop.-1.0

[Andreas Delmelle]

On 11 Jan 2011, at 14:20, Rob Sargent wrote:

Hi Rob

 
 I've proven to myself that I'm generating identical xml, but getting 
 malformed pdf in version 1.0 where 0.95 was perfectly happy.
 
 I'm getting some clipping along the inner (left) side of right-hand pages in 
 static region-before but only on some pages.  Not all pages, however.  It 
 looks as if I've over-lain a high-precedence region-start but it's not in my 
 code :)
 
 Has anyone seen anything like this?
 Attaching the fo.xml for anyone that's curious.

In the future, please pay us curious folk the courtesy of either:
a) providing the *smallest possible* sample reproducing the issue, or
b) describing your issue in more detail

Just mentioning, since, IIC, you sent us about 23 pages of content too many... 
Thanks in advance!

With that many pages and such a vague description, it is hard to see exactly 
what 'malformed pdf' you are referring to.

Do I get it correct that you mean the effect that is visible on page 2?
In that case, do mind that the region-before cannot grow beyond the specified 
extent of 1.5in. If it does, it will overlap the region-body, whether you 
intended it or not.

I am unsure what exactly 0.95 did differently, but I am quite sure that that 
combination of block and nested tables will be too big to fit in the space of 
1.5in. You can see that if you remove the second row of the innermost table 
(containing the block with text 'asdf'). After doing that, the page seems to 
look as it should.



Regards

Andreas


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

Re: Rendering differences: fop-0.95 vs fop.-1.0

[Andreas Delmelle]

On 11 Jan 2011, at 19:31, Rob Sargent wrote:

 My apologies for the size of the fo file.  If I knew where the problem
 was in particular I certain would have trimmed it.  

OK, no harm done.

 I'll follow-up on your suggestions, for which I am most thankful.
 I sent the whole thing since there are pdf differences on most
 of the right hand pages, all of which printed nicely under 0.95.  

If you can be more specific, don't hold back. Quite some time and commits 
passed between 0.95 and 1.0, so I cannot exclude the possibility that there are 
regressions among those differences. The more accurate you can tell what 
appears wrong, the better we will be able to judge whether they are genuine 
bugs or just 'natural' (and in XSL-FO, the latter is at times 
counter-intuitive...).


Regards,

Andreas
---


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

Re: FOP 1.0 - properties which don't make same result than 0.20.5 version

[Andreas Delmelle]

On 10 Jan 2011, at 17:46, (Ext.) Nicolas Salic wrote:

Hi Nicolas

 I’m testing FOP 1.0 with stylesheets currently working with FOP 0.20.5, and I 
 get different results with two properties.
 The height property at fo:table level doesn’t give me the same result, 
 neither the border-style property at fo:table-column level.
  
 Here is the code I use :
snip /

As far as I know, in FOP 1.0:
- height or block-progression-dimension does not work at all on fo:table
- in case of cells spanning multiple colums, the specified column-borders are 
only painted on the cell's start  end (= left  right) edges

For the first issue, there is a quite straightforward workaround: specify 
height or block-progression-dimension on the one fo:table-row instead, 
where it does have the intended effect. Depending on the use case, you may want 
to use min-height if the table may still grow beyond the desired height.

For the second issue, the workaround is not so straightforward, but it could be 
feasible.

It looks slightly convoluted, but below is as close as I could get to your 
0.20.5 output with FOP 1.0. Note that there seems to be a slight issue with the 
height of the row. In order to get it to match the height of the inner table 
exactly, I had to subtract the cell-padding, which does not seem entirely 
correct (?)

?xml version=1.0 encoding=UTF-8?
fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format;
  fo:layout-master-set
fo:simple-page-master margin=1cm page-width=21cm page-height=29.7cm 
master-name=A4Portrait
  fo:region-body/
/fo:simple-page-master
  /fo:layout-master-set
  fo:page-sequence master-reference=A4Portrait
fo:flow flow-name=xsl-region-body
  fo:table width=150mm table-layout=fixed border=solid thin black
fo:table-column /
fo:table-body
  fo:table-row height=96mm
fo:table-cell padding=2mm
  fo:blockCeci est un texte sur plusieurs cellules/fo:block
  fo:block-container absolute-position=absolute top=0mm 
left=-2mm
fo:table width=15cm table-layout=fixed
  fo:table-column border=solid thin black 
column-width=10mm/
  fo:table-column border=solid thin black 
column-width=20mm/
  fo:table-column border=solid thin black 
column-width=30mm/
  fo:table-column border=solid thin black 
column-width=40mm/
  fo:table-column border=solid thin black 
column-width=50mm/
  fo:table-body
fo:table-row height=100mm
  fo:table-cell
fo:block /
  /fo:table-cell
/fo:table-row
  /fo:table-body
/fo:table
  /fo:block-container
/fo:table-cell
  /fo:table-row
/fo:table-body
  /fo:table
/fo:flow
  /fo:page-sequence
/fo:root

Hope this helps!


Regards,

Andreas Delmelle
---


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

Re: FOP 1.0 line feed not visible

[Andreas Delmelle]

On 10 Jan 2011, at 16:22, Philippe Pithon wrote:

Hi Philippe


 Thanks ! good news !
 
 I'll try...FOP Trunk

Just FYI: if it is for testing purposes, and you cannot permit yourself to 
spend time on building FOP yourself, we have nightly snapshot binaries 
available.

In case you're interested, see: 
http://ci.apache.org/projects/xmlgraphics/fop/snapshots/


Regards

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

Re: Urgent: Need help for IKVM dlls

[Andreas Delmelle]

On 07 Jan 2011, at 18:44, Kashipathi, Mamatha wrote:

Hi

We are using these “ IKVM.GNU.Classpath.dll”  ‘IKVM.Runtime.dll”  dll’s 
 in our project along with ApacheFop.Net (v1.0.3705)  poi-2.5.1-dev-20040708

Sorry, wrong list. This is the user list for Apache XML FOP, which is Java 
software. 
The .NET version of FOP is not maintained by Apache. IIRC, it is a Sourceforge 
project, so you might want to have a look around there.

As for Apache POI, this is also originally a Java library, for which the home 
site is http://poi.apache.org. 
No idea who maintains the .NET port of that library...


Regards

Andreas


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

Re: FOP 1.0 line feed not visible

[Andreas Delmelle]

On 07 Jan 2011, at 12:20, Peter Hancock wrote:

Hi Philippe, Pete,

 A little problem with FOP 1.0 (it's works with FOP 0.20.5)
 if I have linefeed (exa 0A) in XML node text, it's not visible in PDF result
 Any ideas ?

 I think perhaps the linefeed-treatment='preserve' property on the
 fo:block may be what you require.
 See  http://www.w3.org/TR/2006/REC-xsl11-20061205/#linefeed-treatment
 for more detail.

That's correct, however, FOP 1.0 still has an issue when combining preserved 
linefeeds with hyphenate=true, so you will also want to remove that attribute 
from the block (or switch to FOP Trunk, where that issue was fixed a few weeks 
ago).

Regards

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

Re: fo:table space-after

[Andreas Delmelle]

On 06 Jan 2011, at 17:51, Philippe Pithon wrote:

Hi Philippe

 I read this attribut on http://www.w3.org/TR/xsl/#spacecond :
 
 Conditionality is an enumerated value which controls whether a 
 space-specifier has effect at the beginning or end of a reference-area or a 
 line-area. Possible values are retain and discard; a conditional 
 space-specifier is one for which this value is discard.
 
 But I don't understand this sentence...
 Do you have a link to a better explanation ?

Not really a link, but the following explanation might make it easier to grasp 
what is happening:
The conditionality component of a space-property has discard as its initial 
value.
This means, in practice, unless you override it to retain, that the space 
will be 'discarded' (thrown away, ignored...) when it appears 'at the beginning 
or the end of a reference area'. 
The latter is XSL-FO-lingo to refer to the cases of space before the first 
object on a page (or in a block-container) and space after the last object on a 
page (or in a block-container).

For the remaining spaces (in between objects on the same page, or in the same 
block-container), it is the precedence component (and ultimately the length) 
that is used to decide which of the spaces 'wins' and will be retained in the 
output.


Hope this helps,


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

RE: FOP 0.95 exception

[Andreas Delmelle]

-Original Message-
From: Alexey Neyman [mailto:sti...@att.net] 

Hi Alexey

 I got the following crash dump from FOP 0.95 when using fo:list-block
inside
 fo:table-cell:

 java.lang.ClassCastException: org.apache.fop.layoutmgr.SpaceElement cannot
be cast to org.apache.fop.layoutmgr.KnuthElement

 It has to do something with widow-content-limit FOP extension. If I remove
either 
 fox:widow-content-limit attribute from fo:table, or space-before
attribute from 
 fo:list-item, there is no exception.

Thanks for the report and the testcase. 
Seems like this is a known open issue, however. 
See also: https://issues.apache.org/bugzilla/show_bug.cgi?id=48380


Regards

Andreas


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

RE: block breaking page-columns

[Andreas Delmelle]

-Original Message-
From: Kester, Peter [mailto:p.kes...@sdu.nl] 

Hi Peter

 I have a page sequence with two columns on the page. 
 Sometimes the content holds a table which should span both columns.
 When this occurs the table gets spanned over the two columns but 
 the part before the column gets pushed above the spanned block:
 The order in my source file is:
 block1, block2, block 3, block 4, wide table, block 5, block 6, block 7,
block 8

snip /
 But I would like to have the following for the column break.
snip /

 It this possible or not?

Provided I am not overlooking something here, I'm afraid not, unless you can
influence the order of the blocks in the source file (which I assume is not
the case, since you explicitly mention that order?)

If you are reasonably certain that block 3 and block 4 together take up the
same amount of space as blocks 5 and 6, then there might be a remote
possibility to 'swap' the blocks if you render to FOP's Intermediate
Format[*] first, but that could get messy, depending on the exact
requirements.
Note that this approach will require you to get familiar with the structure
of the IF. If at all possible, focus on the IF rather than the Area Tree,
since the former is better documented (= for the IF, there is an XML Schema
available).

[*] http://xmlgraphics.apache.org/fop/1.0/intermediate.html


Regards,

Andreas


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

RE: How to XSL-T transform IntermediateFormat within FOP?

[Andreas Delmelle]

 -Original Message-
 From: Stepan RYBAR [mailto:xryb...@seznam.cz] 

Hi Stepan,

 is it possible to perform XSL-T (2.0) transformation within FOP (1.0), 
 *where input file is in IntermediateFormat*? 
 I tried it, but without success (something like unable to mix input mode).


AFAIK, this case is not yet accommodated in FOP 1.0. At least, not from the
command-line. I guess the rationale behind this is that people who use the
IF are considered 'power users', and thus they should have no problem
implementing my below suggestion.

If you are slightly versed in Java and would use FOP embedded, this should
almost turn out to be the proverbial piece of cake.

I would suggest to look closely at a few of the examples that are
distributed with FOP.
See if you can write a small Java wrapper that renders your 'in.xml' to the
IF, uses that IF as input source for a new JAXP transformation (a
Transformer initialized with your 'transB.xsl'), and finally processes the
transformed 'out.if' and renders it to PDF. 
Just yell if you want to try this and need assistance. 
Come to think of it, I don't immediately see why we don't have a Java
example yet that demonstrates this. Am I missing something? 
If that were the case, you could probably almost copy-paste the example code
and be on your way. Right now, it still requires combining a few of the
examples, and a bit of imagination.

IIC, it should be possible to achieve this without even storing the IF as a
physical file and just chain the ContentHandlers (which eliminates
serializing and reparsing the IF altogether). Obviously, you still want to
allow dumping both IF files in case the chain needs to be debugged...

snip /

 Because IF is XML, it should be possible, am I right?

Very right indeed.

 Question is, how effective it could be, when Saxon, I guess, uses
different 
 internal representation of XML (TinyTree) than FOP does (I do not have any

 hints about internals of FOP).

If it is handled programmatically, as suggested above, without storing the
IFs as physical files, then it may require quite some memory, but could turn
out to be significantly faster, as some disk I/O is avoided. 
Going via the command-line (if that were possible) would basically only
eliminate serializing and reparsing the IF for the second transformation,
and some JVM warm-ups in between. As you have to run FOP twice and Saxon
once, going via the command-line requires a Java VM to be started three
times. Keeping this down to one would already save you some.

 P.S. I think, that it could be nice to add to the documentation
step-by-step or 
 example how to use Saxon for XSL-T 2.0 transformation within FOP. It took
me lot 
 of time before I found ...

snip /

Point taken, but still...
One should keep in mind that FOP's _principal_ task is to render _FO_ to
PDF, PS, AFP, etc. 
For convenience, FOP allows the user to specify the input as XML+XSLT, but
delegates the task of that initial transformation (XML to FO) to the
installed XSLT processor. FOP itself is agnostic of the XSLT implementation
that is used at runtime, so one could argue that this is out of scope for
its documentation (?) 

Should we perhaps add step-by-step instructions for _every_ possible XML
parser and XSLT processor? Nice maybe, but I would hope not. 
Before you know it, people will expect us to have step-by-step instructions
for every possible Java runtime, every possible OS...

Also, please don't take this the wrong way, but I entered 'apache fop xslt
2.0' in Google, and the cited mail-thread on Nabble was the first hit.
 
As an alternative suggestion, perhaps you could contribute this information
to the 'HowTos' on the FOP Wiki
(http://wiki.apache.org/xmlgraphics-fop/FrontPage)? That seems like an ideal
place for this type of information. Not immediately FOP-related, but still
very useful to know.


Regards,

Andreas


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

Re: Does FOP support HTML output?

[Andreas Delmelle]

On 27 Mar 2010, at 17:20, David Hoffer wrote:

Hi David

 I'm looking for a tool to generate simple HTML  PDF documents.  I've
 seen websites say FOP can generate HTML but I don't see that listed as
 an output on the FOP site.  Can anyone clarify if this is
 possible/supported?

No, FOP does not support HTML as input or output format. 
Note that HTML /is/ a possible output format for XSLT, so you could opt to have 
one stylesheet to transform your XML to XSL-FO (input for FOP) and another to 
transform it to HTML.


Regards

Andreas

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

Re: Does FOP support HTML output?

[Andreas Delmelle]

On 27 Mar 2010, at 18:05, David Hoffer wrote:

Hi David

 Thanks for that clarification.  In my case I don't have XML, rather I
 just have some calculated data with descriptions.  So I'd me making
 XML just to satisfy tools.  

Well, FOP is an XML application, so you would not get away without using some 
form of XML here. OTOH, the benefits of having an XML representation are that 
you would suddenly have a massive amount of tools/plugins available which 
'know' how to handle your data.

 I realize this is getting off topic for
 this group...but what I really want is a Java tool that can take POJOs
 and generate HTML and/or PDF.

Just to avoid misunderstandings: note that you do not have to create a 
/physical/ XML file to transform Java objects to PDF with FOP. Quite on the 
contrary, unless there is a good reason to create a separate file, that would 
be unnecessary overhead.
See the 'project team' example that comes with FOP. What happens there is a 
conversion from a Java object structure to SAX events. Those events are then 
sent through a fairly simple stylesheet and the resulting XSL-FO is fed to FOP, 
without writing an intermediate file to disk.
There are tools/libraries available that can convert POJO to XML on a generic 
basis (search for JAXB, Castor XML...). 
If your data is in the form of a Java Bean then you certainly will not have to 
reinvent the light-bulb here.

Once you were to use that approach to use FOP to generate PDF from your POJOs, 
then it could be only a very small effort (depending on the structure of your 
data) to write a second stylesheet to handle the transformation to HTML.

One thing you will definitely not escape when going this route is the need to 
learn basic XSLT. Benefit here is that this is a skill that can be applied for 
any form of XML-to-XML transformation.

At any rate, chances are that, if you do find a tool that does both the 
conversions you want to do, it will likely use XML in the background anyway...



Regards

Andreas Delmelle
---


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

Re: spanning page columns not spanning

[Andreas Delmelle]

On 18 Mar 2010, at 19:54, Mario Madunic wrote:

Hi Mario

 (using FOP 0.95 WinXP SP3)
 
 I have the following
 
 fo:block xsl:use-attribute-sets=as_SectionTOCHeading 
 span=allAlphabetical Index/fo:block
 
 And my region is defined as
 
 fo:region-body region-name=sectionBody_AI column-count=2 
 column-gap=0.25in

The most important question is whether the above fo:block is a direct fo:flow 
child...

See 7.21.4 in the XSL-FO 1.1 Rec., where it explicitly says:
Note:
This only has effect on areas returned by a flow; e.g. block-areas generated by 
fo:block children of an fo:flow. Children and further descendants of these 
areas take on the spanning characteristic of their parent.

Could that be the problem here?



Regards,

Andreas Delmelle
---


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

Re: rendering of links to pdf-files on https servers

[Andreas Delmelle]

On 14 Mar 2010, at 19:01, Thomas Bauer wrote:

Hi Thomas,

 External links to pdf-files on http-servers and https-servers seem to
 lead to different output in fop pdf rendering, with the result that
 links to pdf-files on https are not clickable in pdf reading programs.
snip /
 
 The question is whether this is the intended behaviour of fop, or a bug?
 I would prefer that clicking on all types of links leads to a download
 of the corresponding document.

This is definitely a bug.

Technically, see org.apache.fop.pdf.PDFFactory.getExternalAction().
The order of checks is currently so that, for an http://; URL, the code 
generates a PDFUri action, and for an https://; URL ending in .pdf a 
PDFGoToRemote action...

For all other file types, https://; will ultimately also generate a PDFUri. 
It's only the PDF case where it goes wrong...



Regards,

Andreas Delmelle

---


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

Re: table cell margins inherit from parents?

[Andreas Delmelle]

On 10 Mar 2010, at 22:06, Arian wrote:

Hi Arian

 This kinda threw me off,
 I set a margin on a block that contains a table... then i noticed all
 the cells took on the same left margin of the parent.
 Is this inheritance behavior correct?, it seems like the wrong
 behavior for a table cell... (like in css this margin inheritance
 wouldnt happen, so not sure why xsl-fo would want it)

The short answer would be: 
http://wiki.apache.org/xmlgraphics-fop/IndentInheritance

What this comes down to is that the margin-* properties --that exist solely for 
purposes of compatibility with CSS-- are mapped to the native XSL-FO properties 
*-indent. While the former are non-inherited, their native XSL-FO counterparts 
most certainly are.

As pointed out on the Wiki, most implementations choose to ignore this, while 
FOP follows XSL-FO more strictly and forces you to use a configuration setting 
to trigger the CSS-like behavior.

See also: 
http://xmlgraphics.apache.org/fop/0.95/configuration.html#general-elements
(look for element 'break-indent-inheritance')

That said, solving it by resetting start-indent to 0 on the fo:table would 
probably be the cleanest, from an XSL-FO point of view.


Regards,

Andreas
---


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

Re: Unnecessary overhead when running Apache FOP via command line

[Andreas Delmelle]

On 06 Jan 2010, at 20:23, Gregory Buchenberger wrote:

Hi Ville, Gregory,

 Adding more memory to the Java virtual machine seems to help. run the
 java command with something like:

While this may help a bit, it doesn't eliminate the bulk of the processing 
time. At the very best, you could avoid running out of memory by increasing the 
heap size. The effect on the processing time is marginal at best. It just 
causes the garbage collector to run less frequently, which may shave off half a 
second if you're lucky.

If you want to avoid JVM warmup, which probably represents about 80% of the 
mentioned 10 seconds (if not more), then by far the easiest solution is to 
familiarize yourself with the servlet concept.

There is an example servlet that is distributed with FOP, in package 
org.apache.fop.servlet. 
Deploy this in an Apache Tomcat container, and start up Tomcat. If all goes 
well, you can then send simple HTTP requests to the port that Tomcat is running 
on to convert your XML to PDF.

Note that, since the servlet comes as a part of FOP, such a solution requires 
no real Java programming. 
I would estimate at most half a day of work to get yourself basically started, 
even if your Java knowledge is minimal. Do mind the disclaimer on the FOP 
website (link below) concerning the lack of security in that basic servlet. 
Deploying it into a production environment as-is is definitely not recommended, 
so if that is the goal, then eventually you will need to dive into the Java 
code, and enhance it to meet the more rigorous requirements for production 
servers. If you just need to run it on your own system, for your personal use, 
there is no need to modify the servlet.

Obviously, any enhancement that improves this servlet and does not require 
external libraries whose license is not compatible with the Apache license, 
will be warmly welcomed as a donation. ;-)

I think you'll be surprised at how much of those 10 seconds can be avoided, 
with relatively little effort.

More info can be found at: http://xmlgraphics.apache.org/fop/trunk/servlets.html
The source code for the servlet can be viewed at: 
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/servlet/FopServlet.java?revision=732631view=markup
Apache Tomcat can be downloaded here: http://tomcat.apache.org/download-60.cgi


Hope this helps!


Regards,

Andreas Delmelle
---


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

Re: Unnecessary overhead when running Apache FOP via command line

[Andreas Delmelle]

On 06 Jan 2010, at 21:06, Ville Mattila wrote:

 Thank you Gregory for a very prompt reply,
 
 I tried to run the command as you suggested. The result is just a
 little bit faster run, maybe about 5-6 seconds.

Hmm.. seems I underestimated the effect slightly. Still, I'd definitely 
recommend looking into using the servlet.


Regards,

Andreas Delmelle
---


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

Re: fo:table breaks in fo:block-container

[Andreas Delmelle]

On 07 Sep 2009, at 12:22, Vincent Hennebert wrote:


This is an interesting interpretation. There is some discussion about
that on the following bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160

One could return the question, taking the point of view of the  
children

elements of the rotated block-container: when should that content be
broken over to the next page? When its block-progression-dimension
exceeds the available space in block-progression-direction.


No. When it makes the block-container break to the next page, hence  
when its inline-progression-dimension exceeds the block-progression- 
dimension of the block-container.


Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: fo:table breaks in fo:block-container

[Andreas Delmelle]

On 07 Sep 2009, at 18:11, Andreas Delmelle wrote:


On 07 Sep 2009, at 12:22, Vincent Hennebert wrote:


This is an interesting interpretation. There is some discussion about
that on the following bug report:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46160

One could return the question, taking the point of view of the  
children

elements of the rotated block-container: when should that content be
broken over to the next page? When its block-progression-dimension
exceeds the available space in block-progression-direction.


No. When it makes the block-container break to the next page, hence  
when its inline-progression-dimension exceeds the block-progression- 
dimension of the block-container.


Note that this should normally change with XSL-FO 2.0, where in the  
initial requirements (wish-list), there has been explicit demand to  
define such 'vertical' breaks.


Fact remains: the block-progression-direction of the flow does not  
change at all due to the reference-orientation on the block-container.


Difficult to see why other implementations would provide a proprietary  
extension for this, if it's catered for by the Rec anyway...



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: 0.95 text wrap issue

[Andreas Delmelle]

On 03 Sep 2009, at 18:19, Griffin,Sean wrote:

Hi Senthil, Sean,

snip /
1. Remove keep-together on the table-cell.  In this contrived  
example you wouldn't need it.  Not sure if that affects the  
hyphenation behavior or not.


It shouldn't. Specifying an explicit keep-*.within-column does not  
affect line-breaking. If it was plain keep-together, this remark  
would have been spot on, since that would also set the .within-line  
component.


I'm assuming hyphenation was not completely set up.

2. Ensure you have the xml:lang attribute on the page-sequence  
element containing this block or the hyphenation either won't work  
or won't work correctly.


This can indeed be a possible cause. If 'language' is not explicitly  
set, it defaults to none, an obscure language for which OFFO does  
not have hyphenation patterns yet... ;-)



Regards,

Andreas


Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: fo:table breaks in fo:block-container

[Andreas Delmelle]

On 04 Sep 2009, at 21:22, bonekrusher wrote:

Hi Phil


I have a table inside a fo:block-container. The block-container's
orientation is 90 degrees (see attached). When the table rows  
exceeds the
table width, the table does not break to the next page. I've  
attached a

working example. How do I get the the table to break to the next page?


Short answer: you can't. Not with FOP, at any rate.

Longer answer:
I remember playing with a similar case in the past, and realized back  
then that what you seem to expect, is strictly speaking not possible  
in standard XSL-FO 1.1, unless you were to rotate the entire region- 
body.
IIRC, some commercial implementations offer proprietary extensions to  
allow such breaks to be produced. FOP unfortunately does not, yet...


As for the standard: When would the block-container break to the next  
page?
Answer: when its block-progression-dimension exceeds the available  
space in block-progression-direction.
Now, keep in mind that reference-orientation appears to change block/ 
inline-progression-direction for everything that lies *inside* the b-c  
(= it establishes a new coordinate system *within* the b-c's viewport- 
area).
The b-c's height is still its extent in the block-progression- 
direction of the region, which will be determined by the width of its  
content (assuming height=auto, as in your sample)
If the content's height is greater than the region-body's width, then  
that is considered overflow in inline-progression-direction. If we had  
overflow=scroll implemented for AWT, you would at most get a  
scrollbar.
From the point of view of the flow, the block-container's height can  
never exceed the height of the region-body, unless the content's width  
is greater than the region's height.
Even then, FOP chooses to let the content overflow, rather than  
breaking. Rotated block-containers are never broken. (*)


ATM, I'm unsure as to how much/little effort it would take to change  
this. It seems quite possible to allow the nested Breaker to return  
multiple parts instead of removing all breaks, as it does now. That's  
the easy part.
I see a possible difficulty for a block-container that starts, say in  
the middle of a page. On the next page, there is more available space  
for the content-width, but at the time the breaks are first computed,  
we don't really know yet how much that will be. We can only assume it  
is equal to the 'current' available height.
Support for changing page-width has been added to Trunk recently, but  
when only the page-height changes, nothing special happens, and we  
could still get overflow as a result...


(*) Technically: for regular block-containers, the element list is  
inlined into the eventual sequence returned by the FlowLayoutManager  
to the PageBreaker. On the other hand, rotated or absolute-positioned  
block-containers are processed/broken by a nested  
BlockContainerLayoutManager.BlockContainerBreaker, whose  
isSinglePartFavored() returns true. Basically, what the outer  
PageBreaker gets to see here, is a single block.






http://www.nabble.com/file/p25300387/example2.png example2.png
http://www.nabble.com/file/p25300387/example.fo example.fo

Thanks,

Phil
--
View this message in context: 
http://www.nabble.com/fo%3Atable-breaks-in-fo%3Ablock-container-tp25300387p25300387.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




Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: 0.95 text wrap issue

[Andreas Delmelle]

On 03 Sep 2009, at 17:04, senthilvv28 wrote:

Hi

snip /

Case 2:
Long text with No white space like
eg: ReallyReallyLongTextNoWhiteSpace

then the text flows- overlaps the next column.

to fix the problem should i introduce some white space . If yes can  
you let

me know how do it.


That is indeed the recommended workaround for the moment, as FOP does  
no real line-wrapping. We use Unicode line-breaking rules to determine  
whether the content can be broken. If you were to add a couple of Zero- 
Width Spaces in the above word, then FOP will consider those as legal  
breakpoints. If nothing special is done, then the word is considered  
unbreakable (although, you do seem to enable hyphenation, which, if  
correctly configured, should result in at least one break in the  
sample above?)


How exactly you should go about inserting ZWSP in the source text  
depends a great deal on the stylesheet. I can imagine nobody really  
wants to insert a ZWSP between every two consecutive characters in  
every word in the input...



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: keep is not auto but context is

[Andreas Delmelle]

On 25 Aug 2009, at 12:22, Vincent Hennebert wrote:



Keeps do /not/ apply to fo:table-cell:
http://www.w3.org/TR/xsl11/#fo_table-cell
snip /
So whatever that warning means, it is not related to tables.


OK, so I guess it's just a coincidence that the warning appears only  
in table-related tests... Will look into it --sometime ;-)


Later

Andreas

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: keep is not auto but context is

[Andreas Delmelle]

On 24 Aug 2009, at 15:00, Georg Datterl wrote:

Hi Georg


What does this message mean?


It's a warning message, indicating that the current keep-context is  
set to auto, but the keep-property specified on the FO for which  
layout/breaking is performed, has a different value.


I guess the message could probably be set to a lower level (DEBUG) if  
it bothers you...


Regards

Andreas

Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Display of fractions

[Andreas Delmelle]

On 24 Aug 2009, at 13:33, Georg Datterl wrote:

Hi Georg


In my fo file I have a text like
fo:inline font-family=arial bold font-size=4pt line- 
height=8pt baseline-shift=2pt3/fo:inline
fo:inline font-family=arial bold font-size=6pt line- 
height=8pt∕/fo:inline
fo:inline font-family=arial bold font-size=4pt line- 
height=8pt4/fo:inline


The second character is Unicode 2215. When I generate the PDF  
through the batch file from subversion, this sequence looks like 3 /  
4, whereas when I generate the PDF through my application, it is  
pulled together to a bit more than one character width and looks  
like a true fraction. See attached screenshot. Can anybody tell me,  
which part of fop is responsible for this difference and why the  
batch file does not trigger this part?


My best guess would be a difference in white-space in the source FO.  
If you serialize it to disk first, depending on the value of the  
'indent' attribute on xsl:output, the XSLT processor may add white- 
space in between the fo:inlines. When you feed XML+XSLT to FOP in your  
application, the fo:inlines are most likely not separated by white- 
space (a compliant XSLT processor should ignore the 'indent' attribute  
in that case), hence why you get the intended result there.


Note that there is, AFAIK, no combination of related properties in XSL- 
FO that would completely suppress the linefeeds between the  
fo:inlines. There will always at least remain a space, which could be  
a ZWSP if linefeed-treatment is set to treat-as-zero-width-space.
The only fail-safe approach is always to make sure that there is no  
white-space in the FO source that you do not intend to see in the  
eventual output.



HTH!

Andreas

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: keep is not auto but context is

[Andreas Delmelle]

On 24 Aug 2009, at 17:58, Andreas Delmelle wrote:


On 24 Aug 2009, at 15:00, Georg Datterl wrote:


What does this message mean?


It's a warning message, indicating that the current keep-context is  
set to auto, but the keep-property specified on the FO for which  
layout/breaking is performed, has a different value.


Note: AFAICT, this message mainly originates from keeps on table- 
elements for which they are not completely implemented yet. fo:table- 
cells are an example where support for keeps is lacking, but since it  
does work for fo:table-row, and fo:table-cell inherits the value from  
its ancestors...


At any rate, it has no noticeable effect on the output. The warning  
appears for some testcases as well, but would disappear if keeps on  
table-cells would be properly implemented.



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Implementing Change bars

[Andreas Delmelle]

On 21 Aug 2009, at 11:32, Vincent Hennebert wrote:

Hi Vincent

Sorry, I thought you didn’t see that part. Well it’s pretty clear to  
me

then. Just generate empty areas with a border-end.


That indeed seems the most straightforward way to get it implemented  
with as little effort as possible.


The area-handling code that already exists will take care of the  
rest. Why would we want

to write specific code?


Don't know precisely. I don't even know whether it is possible in the  
current setup to paint a border only on a small part of an area...  
Could be interesting for reasons of efficiency, maybe (long shot?)


As another example: for text/character data, the Rec literally states  
that each individual character is a fo:character in the FO Tree. If we  
would have implemented it like that, FOP would be even more of a  
memory-hog than it already is. Strictly speaking, our handling of  
FOText can be considered such 'specific code'.


Ultimately, the actual implementation is of no concern, as long as the  
result is what it should be.



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Implementing Change bars

[Andreas Delmelle]

On 20 Aug 2009, at 12:25, Vincent Hennebert wrote:


Andreas Delmelle wrote:
snip/
No real areas need to be generated, IIC. At most dummy areas, since  
the
change bars are actually no more than additional borders. I wonder  
if we
could get away with partial border painting on the existing flow- 
area(?)


In the description of the fo:page-sequence object [1] it is specified
how change-bar areas must be generated: “Each change bar area is of
class xsl-absolute, with zero margin and padding, with border-end- 
color

given by the change-bar-color of F...”


Guess what? I can read too... :-D

Just meant that, in practice, it may just be a matter of painting  
border fragments. The area would be simply a holder.


Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Auto-generate table of contents

[Andreas Delmelle]

On 20 Aug 2009, at 16:57, Brian Trezise wrote:

Hi Brian

That appears to be for creating links inside the document that point  
to an

external document, no?


Correct, but as I mentioned, I don't think you need to do anything  
special for referring to a specific 'page' in the target document  
(other than appending 'page=xx' to the URI of the external-link in the  
source document)



I'm wanting to create a hyperlink from an external
excel file that opens to a particular point (page, named  
destination, it
doesn't matter) inside the pdf document I'm generating.  Is this  
possible?


That's another matter. If that does not work properly, it could mean  
that Excel does not correctly pass the URL parameters to the PDF  
viewer application, and the bug should be filed with MS. Nothing we  
can do on our end to resolve that, unfortunately...


Again: to simply refer to specific 'pages' in the target PDF, nothing  
special needs to happen for the source PDF.


I'm not having much luck.  Perhaps if I attach the xsl it'll help?   
(I want
an externally-accessible bookmark of some sort for each page created  
with

the xsl:for-each starting on line 162)



The supplied link should be of help, but only if you do not need to  
refer to predefined 'anchors' (not 'pages') in the target document.



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: newFOP taking very long time

[Andreas Delmelle]

On 13 Aug 2009, at 06:11, dschu012 wrote:

Hi

The problem is I want the user to be able to specify the font they  
want to
use to render the PDF. This is very critical when it comes to  
rendering
Asian fonts because the user needs to specify the font they want to  
use they
can render the glyphs they need. After further investigation I think  
I found

someone experiencing a similar problem as me here:
http://www.nabble.com/using-newFOP-only-once-to12615351.html


Just noting: it is a known issue. Sometimes it leads to  
OutOfMemoryErrors, in other cases, it may seem to take an unusually  
long time to detect the fonts. If you use 'auto)detect' feature, FOP  
scans a lot of possible directories, and processes ALL fonts available  
in any of the 'conventional' locations for a given OS.


I'm wondering: if you run in an app-server context, you might just be  
able to sidestep the issue by running one 'dummy' document at  
application startup time. That way you are sure that the burden does  
not fall on the first actual run... Otherwise, indeed, the first run  
will always carry the burden of detecting all the available fonts,  
while from the second run on, the FontCache will be used for that.



Regards

Andreas



Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: font configuration

[Andreas Delmelle]

On 17 Aug 2009, at 14:55, Ming Yu wrote:

Hi Ming


Thanks for the reply. Here is the strange thing.

When I put the order as font=16pt bold arial, the FO engine gives  
this warning:
WARNING: Font 'bold arial,normal,400' not found. Substituting with  
'any,normal,400'.


When I put the order as font=bold 16pt arial , the FO engine gives  
the SEVERE error:
SEVERE: Ignoring property: font=bold 16pt arial (No conversion  
defined bold; property:'font')


In the meantime, I have checked closer, and this is indeed a bug,  
still present in FOP Trunk. As soon as you put single quotes around  
the font-family name, it works as expected. This very simple case, I  
apparently never included in the corresponding testcase, as it only  
checks for lists of font-families or quoted names with spaces... If I  
amend the testcase, the build fails. I have logged Bugzilla 47709 for  
follow-up[*].


Seems that at the time, I was too focused on making font-family lists  
work correctly, and forgot to check the most simple cases. :-/


[*] http://issues.apache.org/bugzilla/show_bug.cgi?id=47709



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Implementing Change bars

[Andreas Delmelle]

On 14 Aug 2009, at 08:53, Stephan Thesing wrote:

Hi Stephan,


Has anybody started to integrated support for the 1.1
fo:begin/end-change-bar elements into FOP?


Not really, but I did have a closer look at some of the requirements  
in the XSL-FO Rec. a while ago, and in my local sandbox, I seem to  
have already created the FObj subclasses at that point, too... :) Not  
very much help, but I can send them to you, if you like.


Good thing is that there is relatively little work on the property  
side. No properties requiring special validation, and the symbolic  
literals for all the new enums (o.a.fop.fo.Constants.EN_xx) and  
properties (PR_xx) have already been committed to Trunk a while back.  
Only FOPropertyMapping needs to be updated to map the additional  
property constants to an appropriate Maker.


One thing in particular I remember are the validation rules, which  
could turn out to be tricky to implement, since the change-bars  
actually form a (possibly nested) structure 'outside' the well-formed  
XML tree.
It even seems possible (IIRC?) for a change-bar-begin to appear in one  
page-sequence, and its corresponding change-bar-end in the next... It  
will require a sort of stack to keep track of the last change-bar- 
begin (in FOEventHandler, or maybe it belongs more in  
FOTreeBuilderContext?), and it is important that this is not cleared  
after the layout for the page-sequence ends.


For the rest, it could turn out to be pretty straightforward, since it  
does not really /affect/ layout.
As Vincent already pointed out, it will need to /involve/ layout  
though, as we would somehow need to mark that the ancestor flow area  
(page or column) needs to be decorated at the start/end side, starting  
at a given position in the column/page.
No real areas need to be generated, IIC. At most dummy areas, since  
the change bars are actually no more than additional borders. I wonder  
if we could get away with partial border painting on the existing flow- 
area(?)



HTH!

Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Auto-generate table of contents

[Andreas Delmelle]

On 19 Aug 2009, at 22:22, Brian Trezise wrote:

Hi Brian

How do you put bookmarks or page markings into the pdf so that you  
can use

(hyperlink)#page=XXX to open the document to a specific page?


See: http://xmlgraphics.apache.org/fop/0.95/extensions.html#named-destinations

HTH!

Andreas


Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: font configuration

[Andreas Delmelle]

On 14 Aug 2009, at 14:21, Ming Yu wrote:

Hi Ming

Hi, I'm trying to make an existing stylesheet to work with my xml  
file. But it has lines like this:


fo:block font=bold 8pt arial and fo:table-cell border-bottom=. 
6pt solid black, etc.


When I compile, the engine complains:

SEVERE: Ignoring property: font=bold 16pt arial (No conversion  
defined bold; property:'font')


Which version are you using exactly. The 'font' shorthand was  
implemented rather late (as of 0.94, IIC).

It should definitely work correctly with 0.95.


Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: font configuration

[Andreas Delmelle]

On 14 Aug 2009, at 20:43, Ming Yu wrote:

Thanks a lot for the reply. I checked my version and found out that  
it's 0.94. So, I upgraded to 0.95. Now the SEVERE error changes to a  
warning:


WARNING: Font 'bold Arial,normal,400' not found. Substituting with  
'any,normal,400'.


Strange... seems like the font-family is parsed as 'bold Arial'. This  
may need to be looked into closer. Are you sure this is nowhere  
specified as such in the FO?


A value like 'font=16pt bold Arial' could lead to the above result.
The right order is style/weight/variant, then size, then font-family,  
and font-family names with spaces are supported, so formally there is  
nothing wrong with that value for the shorthand, even though the order  
is mixed up.




Should I install the font myself somewhere? I'm using Eclipse as my  
IDE.


I also have another question regarding empty table-cell. The  
following lines:


fo:table-cell/fo:table-cell
fo:table-cell border-right=.6pt solid black/fo:table-cell
fo:table-cell border-right=.6pt solid black border-bottom=.6pt  
solid black/


will produce the following error:

fo:table-cell is missing child elements.
Required Content Model: marker* (%block;)+

How can I allow empty cells?


You can turn off strict validation(*), but that is not recommended,  
since it will skip a lot of other validation rules as well, which  
could lead to unpredictable results and makes your FO less portable to  
other implementations.


Better would be to make sure that each cell always contains an empty  
fo:block.



(*) http://xmlgraphics.apache.org/fop/0.95/configuration.html


HTH!


Andreas



Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: FOP Arabic Support

[Andreas Delmelle]

On 09 Aug 2009, at 15:46, Geert Bormans wrote:

Hi Mohammed, Geert,

Just FYI: even when using the correct font, note that FOP currently  
still has some rather severe issues with right-to-left scripts. Even  
when specifying the correct writing-mode, FOP will render the  
characters 'mirrored', and with Arabic, there is also a lack of  
support for inner-word ligatures/glyph-merging...


Just mentioning this, so there are no surprises...


Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: bug in marker processing?

[Andreas Delmelle]

On 08 Aug 2009, at 13:33, Geert Bormans wrote:

Hi Geert


I have hit something that seems to me a bug in FOP.

Is this a known bug?
And if yes, is there a known workaround?

I am listing columns with dictionary terms.
Terms can have long descriptions.
If a term continues to the next page, I need to add an arrow in the  
footer


snip /
In my opinion, I make the marker empty when a term ends on a page  
(see the keep-with-previous)


In Antenna House, this works.
In FOP, I get the arrows, always, which seems wrong to me.
any suggestions?


Is indeed a bug in 0.95 or earlier.
Try FOP Trunk if you can. There was an issue with empty markers, but  
that has been fixed in the meantime.


Also, making the marker contain an invisible character (ZWSP) should  
be enough to sidestep the issue.


HTH!

Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: variable start-indent property

[Andreas Delmelle]

On 30 Jul 2009, at 16:59, Alvaro Moraleda wrote:

Hi


I'm using XSLT and FOP to convert XML to PDF. I need to indent a text
block depending on the number of initial tabs. Example:

--- XML ---
tabtabhello world!!


--- XSLT ---
fo:block start-indent=$initialTabs * 20mm
...
/fo:block


It depends a bit on the exact format of the input. If you have:

texttab/tab/hello world!/text

Then all you would need to achieve the desired result is something like:

xsl:template match=text
  block
xsl:attribute name=start-indent
  xsl:value-of select=count(tab) * 20 /xsl:textmm/xsl:text
/xsl:attribute
xsl:value-of select=. /
  /block
/xsl:template


HTH!

Regards

Andreas

Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandr...@jabber.org


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

Re: Pixel to millimeter conversion for everything (fonts e.t.c) except images

[Andreas Delmelle]

On 30 Jul 2009, at 17:44, HerbertV wrote:

Hi Herbert


Fop use this setting also for conversion of other pixel values. That
behaviour contradict with the behaviour by images as described above.
Because for other elements, for example a font-size of text, with  
pixel
values (other elemens than images) it's true that the higher the  
source

resolution the greater the result!


This was a known issue with FOP 0.95, but has been modified in FOP  
Trunk in the meantime. Trunk exhibits the behavior that you seem to  
expect.


Can you try out FOP Trunk to see if the altered behavior meets your  
requirements?


Regards

Andreas

Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandr...@jabber.org


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

Re: Pixel to millimeter conversion for everything (fonts e.t.c) except images

[Andreas Delmelle]

On 31 Jul 2009, at 12:22, HerbertV wrote:

Hi

UPDATE2: Tested with new xmlgrapics and new fop jar, and works for  
me! Many

thanks. Only one question left: Now i'm not using a release, but a own
build. Is the trunk always stable?


Trunk is not always stable, but there are quite some users using it in  
production environments, so that instabilities get reported and caught  
soon enough. Given that we have a quite extensive test-suite, the  
chances of unstable code getting committed is rather slim (although  
the test-suite obviously does not cover /every/ possible use-case, the  
most common cases are checked, and we have a policy not to commit any  
code that breaks existing tests).



And when comes a new build / release of FOP?


It's somewhat overdue. Initially, a release was planned for early  
2009, but we're running a bit behind here, unfortunately...



Regards

Andreas

Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandr...@jabber.org


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

Re: text-transform and markers

[Andreas Delmelle]

On 29 Jul 2009, at 14:38, Amick, Eric wrote:

Hi Eric

Using FOP 0.95, I ran across what appears to be a bug. The attached  
sample FO file uses text-transform around a retrieve-marker object  
in an attempt to get the text to display in all uppercase. (I know  
text-transform is obsolescent, but it still exists for now, and I  
find it useful at times.)
According to the spec, the text-transform should be applied to the  
text all caps, but it comes out in its original case. The font- 
weight property, on the other hand,  is applied correctly to the in  
bold text. On the second page, I tried using text-transform on the  
block inside the marker, but it didn't work any better. Note that  
text-transform works fine when it is not used in conjunction with  
marker or retrieve-marker, as illustrated on both pages. Am I  
missing something?


No, seems like a bug indeed. One positive note is that, I also tried  
running it through FOP Trunk, and the issue seems to be resolved there  
already.



Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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

Re: Problems with table-cells and unwanted padding

[Andreas Delmelle]

On 26 Jul 2009, at 14:09, samea wrote:

HI Markus

I want to have Table-cells with no padding to place images correct,  
but the

fop does allway some padding.  http://www.nabble.com/file/p24666448/fop.gif
how is it possible to set that of?


IIC, the 'padding' is actually not padding in the strict sense. It  
results from what is called the line's 'half-leading'. In text  
paragraphs, this is responsible for the regular line-spacing (= 2 x  
10% of the current font-size for each line).


Your options to avoid that: set either font-size or line-height to 0pt  
on the surrounding block, and the spacing will disappear.



HTH!


Andreas

Regards,

Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandr...@jabber.org
skype: adlm0608

---


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