Re: NPE

[Glen Mazza]

Andreas L Delmelle wrote:


In the latter case, however:


  
  ...
  


Note that the i-f-o now contains two text nodes (= #PCDATA):  
'
  ' and ' '




I think they call that "insignificant white space", and that would not 
be counted as PCDATA.  Partly explained here, but not definitive either way:


http://www.w3.org/TR/REC-xml/#sec-white-space

Also, this old email[1], which included the above link, has an 
interesting quote of how to interpret whitepace:


Whitespace verifies as #PCDATA if #PCDATA is allowed at a particular 
point.  If #PCDATA is NOT allowed at a particular point, the whitespace 
is ignored for the purposes of verifying.


[1] http://lists.xml.org/archives/xml-dev/199806/msg00386.html

But I'm far from an expert on this stuff.

This means we have a choice to either test every one of those  
characters, or let the 'error' slip through, possibly with a warning.  
Depending on the context, I can imagine users not being very happy if  
FOP were to be unconditionally strict here... [suppose i-f-o is on  one 
of the last pages of a 250 page document :-/]




I don't think that whitespace-only nodes are being created by FOP 
anyway, if the whitespace just exists between two consecutive opening 
tags.  So this problem may not be occuring for the user as it is.


But it is a common misperception[2] that strict validation is 
mean and cold-hearted, when in fact is it saves people from submitting 
erroneously built documents/invoices.  "Just a warning" means that the 
user is required to scroll through the log output of every document 
generation, just to make sure that the document FOP produced is valid, 
and if they fail to do that, then they may submit an incorrect document 
or invoice.  For every hacker irritated by strict validation, two or 
three are probably saved by it--especially billing invoices, where you 
almost certainly would want to halt if you had an XSLT error which would 
otherwise cause an invalid invoice to be created.


Thankfully FOP has both a strict and non-strict version to suit either 
preference.  Human nature being what it is though, most who clamor for 
the latter, as soon as it is provided to them, start using the former 
anyway.


Glen

[2] http://marc.theaimsgroup.com/?l=fop-dev&m=111365780207108&w=2


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: FOP Example Servlet error

[J.Pietschmann]

Sir Strongbad wrote:

I am trying to test it by passing it a
simple XML and XSL document, but it is generating an error as seen
below, in Tomcat.  Is the servlet no seeing the stylesheet?


That's the most probable cause. Another possibility is a faulty
style sheet.
Test your source XML+XSLT using the FOP command line application,
in order to see whether this works.
The path to the style sheet must be either relative to tomcat's CWD,
or a full absolute path (it is not run through the URIResolver).

J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

FOP Example Servlet error

[Sir Strongbad]

After a little trouble (and MUCH help from this board!) I was able to
run the FOP servlet build.  I am trying to test it by passing it a
simple XML and XSL document, but it is generating an error as seen
below, in Tomcat.  Is the servlet no seeing the stylesheet?  I have
tried passing the whole path to the XSL, but to no avail.   Any
suggestions?  Thanks in advance...

javax.servlet.ServletException: Could not compile stylesheet
FopServlet.doGet(Unknown Source)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419)

org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:133)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)


root cause

org.apache.fop.apps.FOPException: Could not compile stylesheet

org.apache.fop.apps.TraxInputHandler.initTransformer(TraxInputHandler.java:108)
org.apache.fop.apps.TraxInputHandler.(TraxInputHandler.java:84)
org.apache.fop.apps.XSLTInputHandler.(XSLTInputHandler.java:71)
FopServlet.doGet(Unknown Source)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:419)

org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:133)
javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

alternatives to floats in fop

[Johannes Künsebeck]

Hi,
I try to build a complex design with fop, the design-template can be
seen here :

http://yucca-net.de/data/gild.pdf

After toying around with fop, I'm not sure if it is possible to realize
this design with fop.
I got alternating page-masters and the background-design working.
I can format a fo:block with the design for the even page, I can format
a fo:block with the design for the odd page, but I can't specify when to
use which (the problem you can't see in the template is that it must be
possible to put two or more workshops on one page).

My thoughts so far (not very far):
- use float="inside|outside" (XSL1.1) but that's not supported in fop
- put date and time infos in region-start/end, but how can I synchronize
startpositions with the flow?

So my questions are
- Do you think it is possible to realize this with XSLT-FO (& maybe
extensions)
- Do you think it is possible to realize this with fop?
- If yes, what do I have to read, to get it working
thanks in advance,  Hann*
*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fonts

[Andreas L Delmelle]

On Mar 7, 2006, at 19:26, Andreia Oliveira wrote:

Hi,


This new approach was attempted (separate templates as suggested).
The result is the text inside field1 is not touched at all (as  
before). It

remains as before without any tranformation.
It seems to me that fop is not even applying the template despite  
the fact

that the xml file as references to  and  elements.


Just to get this straight: FOP never applies templates. That's the  
XSLT processor's job (Xalan, Saxon...).



Maybe I did not explain myself clearly about my purpose:
Inside one XML field  (fo:block) some  and  tags may  
appear.
If so, fop, when generating the should generate the text inside the  
 and

 tags in italic and bold.


Starting from something like:


  Unformatted text with some italic and
  bold, maybe some
  bold-italic, or even
  italic-bold?


Use this template for the 'field' nodes:


  

  


and the following two for the 'em' and 'strong' nodes:


  

  



  

  


would lead to the output (indented for readability)


  Unformatted text with some
  italicbold
bold-italic
italic-boldShould do the job nicely, unless there is another error hidden  
somewhere...


Cheers,

Andreas


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Fonts

[Andreia Oliveira]

Hi.
This new approach was attempted (separate templates as suggested).
The result is the text inside field1 is not touched at all (as before). It
remains as before without any tranformation.
It seems to me that fop is not even applying the template despite the fact
that the xml file as references to  and  elements.

Maybe I did not explain myself clearly about my purpose:
Inside one XML field  (fo:block) some  and  tags may appear.
If so, fop, when generating the should generate the text inside the  and
 tags in italic and bold.

Is this the correct approach for this process?

-Original Message-
From: J.Pietschmann [mailto:[EMAIL PROTECTED] 
Sent: terça-feira, 7 de Março de 2006 15:15
To: fop-users@xmlgraphics.apache.org
Subject: Re: Fonts

Andreia Oliveira wrote:
...
> An xml file, a xsd and a xslt were created.
Fortunately, schema definitions (XSD) are irrelevant for FOP.

> (Example: Here is my text. It will be 
> difficult to get it formatted 
> correctly)

> 
This matches elements with the name "XMLContent". There are no such elements
in your source file, because XMLContent is a *type*, therefore this template
never triggered. In you case this makes not much of a difference, because
you basically want the default template behaviour anyway.
You can't match types unless you are using a XSLT2 processor.

>   />
^
This will duplicate the first text node of the element, because all child
nodes (including all text nodes) have already been processed by the
apply-templates above.

> 
You should never start a template match with a "//".

> 
> 
Matching multiple elements and then dispatching again inside a template is
considered bad style.

You should have written two templates:

   
  
   



   
  
   


Note further that you should use fo:wrapper instead of fo:inline, unless you
really want to generate inline areas.

J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: NPE

[Andreas L Delmelle]

On Mar 7, 2006, at 02:38, Glen Mazza wrote:

Hi Glen,


Andreas L Delmelle wrote:


On Mar 6, 2006, at 10:05, Florent Georges wrote:


The fo:instream-foreign-object flow object has a child
from a non-XSL namespace. The permitted structure of
this child is that defined for that namespace.

  So it is required to an IFO to have a child element, isn't
it?

Yes. Exactly one child that is not in the XSL-FO namespace.

  And to don't have non-whitespace #PCDATA.  Right?

Hmm... Yes, if I catch your intention correctly.

So an FO validator would have to report an error for both the
above IFOs, isn't it?
I'd think so, yes. OTOH, if you have an i-f-o that contains some   
text, and then a foreign XML node, I'd assume that a warning  
would  suffice...


I disagree, although not enough to resubscribe to FOP-DEV and veto  
such a matter.  PCDATA isn't allowed for fo:i-f-o.  Those FO's  
which may have PCDATA are expressly defined in the XSL specification.


I see your point... maybe we can do something with the  
strictValidation switch here. My concern here is that the first two  
cases are obviously wrong (since the required non-XSL child node is  
absent).

In the latter case, however:


  
  ...
  


Note that the i-f-o now contains two text nodes (= #PCDATA):  
'
  ' and ' '


This means we have a choice to either test every one of those  
characters, or let the 'error' slip through, possibly with a warning.  
Depending on the context, I can imagine users not being very happy if  
FOP were to be unconditionally strict here... [suppose i-f-o is on  
one of the last pages of a 250 page document :-/]


Any other opinions on this?

Cheers,

Andreas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fonts

[J.Pietschmann]

Andreia Oliveira wrote:
...

An xml file, a xsd and a xslt were created.

Fortunately, schema definitions (XSD) are irrelevant for FOP.


(Example: Here is my text. It will be difficult to
get it formatted correctly)





This matches elements with the name "XMLContent". There are no
such elements in your source file, because XMLContent is a *type*,
therefore this template never triggered. In you case this makes not
much of a difference, because you basically want the default template
behaviour anyway.
You can't match types unless you are using a XSLT2 processor.





   ^
This will duplicate the first text node of the element, because
all child nodes (including all text nodes) have already been processed
by the apply-templates above.




You should never start a template match with a "//".





Matching multiple elements and then dispatching again inside
a template is considered bad style.

You should have written two templates:

  
 
  



  
 
  


Note further that you should use fo:wrapper instead of fo:inline, unless
you really want to generate inline areas.

J.Pietschmann

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RE: Fonts

[b . ohnsorg]

- original Nachricht 

Betreff: RE: Fonts
Gesendet: Di 07 Mär 2006 15:26:38 CET
Von: "Andreia Oliveira"<[EMAIL PROTECTED]>

> I proceeded as suggested.
> The fo file generated by step 1 has no reference to the  or 
> elements.
To be honest: This is not a FO-problem. You should refer to a XSL-mailing 
list...

Basically you do something like:


 
 
 



 
  
 


So the first template applies to your starting tag, and hands over control to 
other templates, if available. Maybe it's your XPath-syntax (I'm not familiar 
with this, too *g*), which does not match to your XML-structure (I'm quite sure 
it doesn't, I'm concerned about that double slash. But I'm definitely sure, 
that a slash at the beginning means the xml's root. Relative XPath-expression 
should not contain a slash at the beginning, but may contain them between the 
nested tag's names. Correct me, if I'm wrong). There's no error due to a 
correct XML- and XSL-structure but no content matching the XPath-expressions.

Maybe you have a look at the docbook-stylesheets, the contain tons of 
implementation samples to transform rather complex nested xml to fop-renderable 
XSL-FO. I'd prefer to store the formatted text as  so it's possible to hand it over to the FO-document 1:1. Another 
way would be to use parts of the DocBook-stylesheets and adapt them to your 
tagging (better to reuse existing code than re-inventing it).

> Proceeded to step two and final pdf file was not generated as supposed. 
If you don't by four, a cake will lack of 70% matter (which cannot be replaced 
by dark matter floating 'round the universe and did not recombine to pure 
energy causing a temperature rise within the kitchen-system). And here the 
result won't be the same as on the cookbook's picture.

To sum it up: This is definitely off-topic, I'm not scared of extra mail but 
often it needs longer to get an answer if it doesn't belong to the list's 
context. And if your XSL-FO contains all that fancy formatting but FOP still 
does not render it as expected, then return to this list...
> 
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
> Sent: terça-feira, 7 de Março de 2006 13:02
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Fonts
> 
> 
> - original Nachricht 
> 
> Betreff: Fonts
> Gesendet: Di 07 Mär 2006 13:42:47 CET
> Von: "Andreia Oliveira"<[EMAIL PROTECTED]>
> [...]
> > pdf (using command line), the tags are completely ignored (no text is
> output in bold or italic)Also, in the log fop generates on the screen it
> does not return any error regarding the fonts. It outputs "[INFO] setting
> up
> fonts" and continues... Can someone help? 
> 
> Did you check your transformation without FOP, e.g. take an extra step to
> see, if the FO contains the font-formatting attributes?
> 
> 1. XML->XSLT->FO (xstlproc, xalan, saxon...) 2. FO->FOP-PDF (FOP)
> 
> Thanks, --Andreia
> [EMAIL PROTECTED] 
> 




"Jetzt Handykosten senken mit klarmobil - 14 Ct./Min.! Hier klicken"
www.klarmobil.de/index.html?pid=73025


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Fonts

[Andreia Oliveira]

I proceeded as suggested.
The fo file generated by step 1 has no reference to the  or 
elements.
Proceeded to step two and final pdf file was not generated as supposed. 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: terça-feira, 7 de Março de 2006 13:02
To: fop-users@xmlgraphics.apache.org
Subject: Re: Fonts


- original Nachricht 

Betreff: Fonts
Gesendet: Di 07 Mär 2006 13:42:47 CET
Von: "Andreia Oliveira"<[EMAIL PROTECTED]>
[...]
> pdf (using command line), the tags are completely ignored (no text is
output in bold or italic)Also, in the log fop generates on the screen it
does not return any error regarding the fonts. It outputs "[INFO] setting up
fonts" and continues... Can someone help? 

Did you check your transformation without FOP, e.g. take an extra step to
see, if the FO contains the font-formatting attributes?

1. XML->XSLT->FO (xstlproc, xalan, saxon...) 2. FO->FOP-PDF (FOP)

Thanks, --Andreia
[EMAIL PROTECTED] 

--- original Nachricht Ende 




Ihr Traumpartner ist nur einen Klick entfernt. 1 Million Singles warten auf
Sie in Deutschlands beliebtester Partnerboerse:
http://singles.freenet.de/index.html?pid=11512


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fonts

[b . ohnsorg]

- original Nachricht 

Betreff: Fonts
Gesendet: Di 07 Mär 2006 13:42:47 CET
Von: "Andreia Oliveira"<[EMAIL PROTECTED]>
[...]
> pdf (using command line), the tags are completely ignored (no text is output 
> in bold or italic)Also, in the log fop generates on the screen it does not 
> return any error regarding the fonts. It outputs "[INFO] setting up fonts" 
> and continues... Can someone help? 

Did you check your transformation without FOP, e.g. take an extra step to see, 
if the FO contains the font-formatting attributes?

1. XML->XSLT->FO (xstlproc, xalan, saxon...)
2. FO->FOP-PDF (FOP)

Thanks, --Andreia [EMAIL PROTECTED] 

--- original Nachricht Ende 




Ihr Traumpartner ist nur einen Klick entfernt. 1 Million Singles warten auf Sie 
in
Deutschlands beliebtester Partnerboerse:
http://singles.freenet.de/index.html?pid=11512


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Hello, about fop

[b . ohnsorg]

- original Nachricht 

Betreff: Hello, about fop
Gesendet: Mo 06 Mär 2006 23:39:57 CET
Von: "chinlu chinawa"<[EMAIL PROTECTED]>

> I understand dockbook/XML-XSLT/SGML-DSSSL and it's
> customization layers as a good way of working,
> although I'd like an expert to advise me.

http://www.sagehill.net/docbookxsl/index.html

> I'd be working on a pdf output basis or any other
> format that would be better for a press to work with.
> I'm within a linux system, and have no troubles at all
> when starting to learn all over again, tex or any
> other format any one could advise me as "the most
> proffesional one" when dealing with presses (is that
> how you call those places that actually print out your
> book, isn't it?), sorry my english anyway.

Dunno what this all about, I only use fop 0.91, even on a HP-UX 11 and I also 
rendered fancy svg into PDF-outputs. My only advice would be: 
OpenOffice->"Export As «SVG»"->insert into FO (or docbook-resource, have a look 
at the "mediaobject") and run fop. Maybe it's not the right way to design 
flyers and graphical complex structures. Therefore leave the fo-step and export 
directly from OpenOffice...(if it runs on your box, at all). TeX and LaTeX is a 
bit more complicated, try starting with "LyX", if it compiles/runs on your 
glibc-whatever *g*









-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Fonts

[Andreia Oliveira]

Hi. I am a newbie in 
FOP and I am struggling with a question regarding fonts.
 
I inherited a 
project from a colleague and I am a bit lost.
 
We want to generate 
pdf files. For that, currently (and until we have a complete database structure 
built / and the .net engine that will generate these pdf files), we are doing 
some tests to understand if we will be able to generate the files as requested 
using fop.
 
An xml file, a xsd 
and a xslt were created.
The xml file has a 
special tag that we called XMLContent because it will contain tags like 
 and  inside the text. 
(Example: 
Here is my text. It will be difficult 
to get it formatted 
correctly)
The xsd defined the 
proper fields as being of type XMLContent: 


  
The xslt has a 
section were it tries to handle these xml tags.

  
  
  
  xsl:template>
  
  
  
  rgb(0,255,0)xsl:attribute>
  xsl:if>
  
  boldxsl:attribute>
  xsl:if>
  
  fo:inline>
  xsl:template>
But, when I try to 
generate the pdf (using command line), the tags are completely ignored (no text 
is output in bold or italic)
Also, in the log fop 
generates on the screen it does not return any error regarding the fonts. It 
outputs "[INFO] setting up fonts" and continues...
 
Can someone 
help?
 
Thanks,
 
--
Andreia Oliveira
[EMAIL PROTECTED]
---
 

Re: page sequencing for parallel print

[Jeremias Maerki]

Partially. We've already implemented the bookmark feature in 0.91beta.
Other features will be added as people invest effort into FOP.

On 07.03.2006 11:33:11 Christiane Fritze wrote:
> Will the next FOP follow the new XSL 1.1 candidate recommendation?


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: page sequencing for parallel print

[Christiane Fritze]

Jeremias,

thank you for your informations. I already looked at the XSL 1.1 
recommendation
but I think the flow-map too will not work in my case because I need 
some page

related fo functions like page number, running headers etc...

So I will have a look at the PDF post processors.

Will the next FOP follow the new XSL 1.1 candidate recommendation?

Thanks,
Christiane

Jeremias Maerki schrieb:


Hmm, I don't think that will help Christiane. This doesn't allow you to
alternate between two flows. XSL 1.0 only supports one flow per
page-sequence. Maybe the flow maps in the upcoming XSL 1.1 might help.
But these are not supported by FOP, yet.

My suggestion is to render the two editions after each other in two
separate page-sequences and then using a PDF post-processor [1] to
rearrange the page order inside the document.

[1] http://xmlgraphics.apache.org/fop/resources.html#products-pdf

On 07.03.2006 00:54:27 Karl Roberts wrote:
 

Check out http://xmlgraphics.apache.org/fop/fo.html#fo-oddeven 


It'll show you how (basically you set up a  that contains
's for your left and right hand
 then make your 

Cheers

Karl

-Original Message-
From: Christiane Fritze [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, 7 March 2006 3:54 AM

To: fop-users@xmlgraphics.apache.org
Subject: page sequencing for parallel print

Hi all,

for a parallel printed edition I need two different transformations of
the same xml-document, which is easily made by means of the 'mode' 
attribute.


Parallel printed means that one version of the text has to be on all odd
pages, the other version on all even pages (if you need see below).

If two s in s were allowed, I could have
somthing like this:

 
>
...

  


   
 


So I need two s (for the complete strucure of my
fo.xsl see below).
But how do I have to handle the s to get an
page-alternately rendered text?

| page 1 |page 2 |
||   |
| text version one text  |  same text version two sa | version one text 
| vers  |  me text version two same |

| ion one text version   |  text version two same te |
| one text version one   |  xt version two same text |
| text version one text  |  version two same text ve |


| page 3 |page 4 |
||   |
| version one text vers  |  rsion two same text vers |
| ion one text version   |  ion two same text versio |
| one text version one   |  n two same text version  |
| text version one text  |  two same text version tw | version one text 
| vers  |  o same text version two  |


and so on...


I use FOP 0.91 beta.

Thank you in advance for any help.
   




Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Changing logging behavior in an embedded application.

[Eckard_Buchner]

you are right the trunk version is fine.
I am still using the 0.20 version but I will soon upgrade
Eckard






Jeremias Maerki <[EMAIL PROTECTED]>

07.03.2006 10:17



Bitte antworten an
fop-users@xmlgraphics.apache.org





An
fop-users@xmlgraphics.apache.org


Kopie



Thema
Re: Antwort: Re: Antwort: Re: Changing
logging behavior in an embedded application.








If the TTFReader is supposed to be used as an embedded
component, it's
best to separate the logic from the command-line interface. System.out
calls would then not be permitted in the logic, only in the command-line
interface. I don't like when things are mixed. I've just had a look at
the code and as far as I can see, all log calls go to the logger, so it
would actually be only a matter of setting up the logging right in your
case. You may not even have to change anything. I did not remember that
the whole thing was so well cleaned-up already.

On 07.03.2006 10:06:31 Eckard_Buchner wrote:
> i could do something like this: Add a parameter -v (verbose) and doing

> system.out only when this parameter is set. Additionally there would
be a 
> boolean property, because when I embed the reader I do not use the
main() 
> method. Do you agree?
> 
> Eckard
> 
> 
> 
> 
> Jeremias Maerki <[EMAIL PROTECTED]> 
> 07.03.2006 08:45
> Bitte antworten an
> fop-users@xmlgraphics.apache.org
> 
> 
> An
> fop-users@xmlgraphics.apache.org
> Kopie
> 
> Thema
> Re: Antwort: Re: Changing logging behavior in an embedded application.
> 
> 
> 
> 
> 
> 
> You're welcome to improve TTFReader in FOP Trunk if it doesn't do
> exactly what you want it to do. TTFReader was never designed to be
used
> as anything else than a command-line tool which is called once for
each
> font. If people have additional needs we're gladly accepting patches
> against FOP Trunk.
> 
> On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > > FOP does have a few System.out.println calls in its source
code but
> > > these are only in places where those are ok, i.e. in command-line
> > > handling code
> > 
> > IMHO this is not the case with the TTFReader. It tells you about
each 
> file 
> > it reads and writes. If you convert a couple of files at once
this is a 
> > little inconvenient. Maybe it should have a silent mode? BTW
if you 
> embed 
> > the TTF Reader i would prefer getting exceptions when something
goes 
> wrong 
> > rather than geting null return (and a stack trace in stdout)
> 
> 


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application.

[Jeremias Maerki]

If the TTFReader is supposed to be used as an embedded component, it's
best to separate the logic from the command-line interface. System.out
calls would then not be permitted in the logic, only in the command-line
interface. I don't like when things are mixed. I've just had a look at
the code and as far as I can see, all log calls go to the logger, so it
would actually be only a matter of setting up the logging right in your
case. You may not even have to change anything. I did not remember that
the whole thing was so well cleaned-up already.

On 07.03.2006 10:06:31 Eckard_Buchner wrote:
> i could do something like this: Add a parameter -v (verbose) and doing 
> system.out only when this parameter is set. Additionally there would be a 
> boolean property, because when I embed the reader I do not use the main() 
> method. Do you agree?
> 
> Eckard
> 
> 
> 
> 
> Jeremias Maerki <[EMAIL PROTECTED]> 
> 07.03.2006 08:45
> Bitte antworten an
> fop-users@xmlgraphics.apache.org
> 
> 
> An
> fop-users@xmlgraphics.apache.org
> Kopie
> 
> Thema
> Re: Antwort: Re: Changing logging behavior in an embedded application.
> 
> 
> 
> 
> 
> 
> You're welcome to improve TTFReader in FOP Trunk if it doesn't do
> exactly what you want it to do. TTFReader was never designed to be used
> as anything else than a command-line tool which is called once for each
> font. If people have additional needs we're gladly accepting patches
> against FOP Trunk.
> 
> On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > > FOP does have a few System.out.println calls in its source code but
> > > these are only in places where those are ok, i.e. in command-line
> > > handling code
> > 
> > IMHO this is not the case with the TTFReader. It tells you about each 
> file 
> > it reads and writes. If you convert a couple of files at once this is a 
> > little inconvenient. Maybe it should have a silent mode? BTW if you 
> embed 
> > the TTF Reader i would prefer getting exceptions when something goes 
> wrong 
> > rather than geting null return (and a stack trace in stdout)
> 
> 


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Hello, about fop

[chinlu chinawa]

Well, I got both jdk, and jre installed (1_3_1_17), I
mean, the did decompress.

They need at least glibc-2.2.4, whilst mine is 2.2.1.
Could not even build fop because of this, therefore
there's no way it would run either, so I got rid of
all.

I wouldn't say this is any odd problem at all, but a
simple glibc dependency issue, though. 

My compiler and glibc are a bit older, as in my
opninion, nobody needs a glibc eating a hundred more
megabytes of memory after each release, and I can
compile new applications as they come out (and I need
them), but the rest of my system is up to date, and
haven't had any problem I couldn't solve. 

Anyway, I've only used java because of fop, and is
just that we don't need to, this is unix.

Ahm, yes I'm sure that 0.91 is a proper production
tool, but I cannot say same of 0.20.5. It's alright
for simple documents, though. But when you start
dealing with tables, or footers or headers, and you
need precision, there's no way, or that's been my
experience.

Well, you didn't point out me anywhere, I've been
reading about tex, and it looks quite powerfull and
robust, I whish I would have started with it from the
begining, so I'll do it now.

Best Regards guys,




___ 
To help you stay safe and secure online, we've developed the all new Yahoo! 
Security Centre. http://uk.security.yahoo.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Antwort: Re: Antwort: Re: Changing logging behavior in an embedded application.

[Eckard_Buchner]

i could do something like this: Add
a parameter -v (verbose) and doing system.out only when this parameter
is set. Additionally there would be a boolean property, because when I
embed the reader I do not use the main() method. Do you agree?

Eckard






Jeremias Maerki <[EMAIL PROTECTED]>

07.03.2006 08:45



Bitte antworten an
fop-users@xmlgraphics.apache.org





An
fop-users@xmlgraphics.apache.org


Kopie



Thema
Re: Antwort: Re: Changing logging behavior
in an embedded application.








You're welcome to improve TTFReader in FOP Trunk if
it doesn't do
exactly what you want it to do. TTFReader was never designed to be used
as anything else than a command-line tool which is called once for each
font. If people have additional needs we're gladly accepting patches
against FOP Trunk.

On 07.03.2006 08:23:56 Eckard_Buchner wrote:
> > FOP does have a few System.out.println calls in its source code
but
> > these are only in places where those are ok, i.e. in command-line
> > handling code
> 
> IMHO this is not the case with the TTFReader. It tells you about each
file 
> it reads and writes. If you convert a couple of files at once this
is a 
> little inconvenient. Maybe it should have a silent mode? BTW if you
embed 
> the TTF Reader i would prefer getting exceptions when something goes
wrong 
> rather than geting null return (and a stack trace in stdout)




Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hello, about fop

[chinlu chinawa]

Hi guys,

I've been around the installation of trunk's version of FOP, which I've
ended up by not being able to use beacuse of my system is too old
(libc-2.2, gcc 2.95.3), and the java version you've lately updated to,
doesn't run here.

Actually, the only version I'd able to use, would be 0.20.5. The thing
is this version doesn't respect my custom footers (the body overrides
it), body text doesn't start neither at the same possition when using
this footers, etc.

So I'm just wondering whether could anyone please tell about other resources? 

I'd like to be able to generate nice-looking documents, I mean with svg
or anyother scalable imaging format, etc. For this time, I'll be
publishing in C5 (paper size), don't know whether this would a problem
or not.

I understand dockbook/XML-XSLT/SGML-DSSSL and it's customization layers
as a good way of working, although I'd like an expert to advise me. 

I'd be working on a pdf output basis or any other format that would be
better for a press to work with. I'm within a linux system, and have no
troubles at all when starting to learn all over again, tex or any other
format any one could advise me as "the most proffesional one" when
dealing with presses (is that how you call those places that actually
print out your book, isn't it?), sorry my english anyway. 

I've been for a while away from any of this, but I do remember there
are formats such as dvi, postscript, I know one can have pdf from sgml
+ jadetex, that one can use it even with dsssl or xslt style-sheets
(IIRC). 

I'd really appreciate, though, if someone could advise when getting
into something that's gonna be stable, robust, and is not gonna break
any of my work beacuse of thirdy-party dependencies, whilst being able
to generate good-looking documents as well as dealing with presses, or
printing-presses at highest level.

Kind Regards,

Re: Chinese hyphenation particularity

[Jeremias Maerki]

UAX#14 is specified here:
http://www.unicode.org/reports/tr14/

If you're serious about diving into this, keep in mind that this is
probably not a small job and will require some amount of getting
acquainted with FOP and its innards. It's also recommended that you
subscribe to the fop-dev mailing list and that you browse through the
mailing list archive for the fop-dev mailing list where you will find
some discussions and preparational work already done (mostly by Joerg
Pietschmann). Search words are "UAX", "UAX#14", "Unicode", "TR14", "i18n",
"line breaking". We were recently talking about using ICU4J
(http://icu.sourceforge.net/). Its use may give us a good head-start.
Joerg Pietschmann and Manuel Mall already did some work in the area:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200510.mbox/[EMAIL 
PROTECTED]

I can't help much here because I haven't had the time to get a closer
look at all this.

On 07.03.2006 09:11:47 Nicolas Lalevee wrote:
> Jeremias Maerki a écrit :
> > There's not much else you can do other than to try to handle/work-around
> > everything in XSLT. FOP does not have special code to handle languages
> > like Chinese. We lack the knowledge set in the project team. Every now
> > and then we talk about implementing UAX#14 line breaking but so far
> > nobody had the resources to dive into this. Any help is welcome.
> 
> OK,
> In fact, I haven't find any formatter that does that. XSL Formatter
> doesn't support that (said the Antenna House support), no answer yet of
> XEP support.
> So the only way to do a such hyphenation is to code it myself in FOP. So
> maybe I will be involved in that stuff, depending of the work to do.
> Can I have more info about the "UAX#14" ?
> 
> bye,
> Nicolas
> 
> > 
> > On 06.03.2006 10:48:24 Nicolas Lalevee wrote:
> > 
> >>Hi everybody,
> >>
> >>I have succeeded in producing a chinese PDF from an XML document via a
> >>XSL transformation.
> >>There is a last problem. The professional chinese document should not
> >>let a chinese character alone on a line.
> >>For instance, I have the sentense "AZERTYUIO." to render in PDF. FOP
> >>(with the patch of the bug 36977 for the trunk version), generate a PDF
> >>with :
> >>AZERTYUI
> >>O.
> >>
> >>And, for chinese people, that's not a well rendered document. The
> >>prefered layout is :
> >>AZERTYUIO. (the characters have to be compressed)
> >>or
> >>AZERTYU (the characters have to be expanded)
> >>IO.
> >>
> >>The only way I found to do so is to force the last three characters of a
> >>text to be "no-wrap". Here is my XSL template :
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >>select="'.'" />
> >> >>select="'.​'" />
> >>
> >>
> >>
> >> >>select="'\​'" />
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> >>keep-together.within-line="always">
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>And that's a not good solution because some ends of line can be missed.
> >>In my XML source document, I can have inline formatting properties, like
> >>bold or italic, that makes the text sequence shorter than 3, even if the
> >>complete sentense contains more than 3 characters.
> >>
> >>Is there any other way to handle this hyphenation particularity ?
> >>
> >>Thanks in advance
> >>Nicolas
> > 
> > 
> > 
> > Jeremias Maerki


Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Chinese hyphenation particularity

[Nicolas Lalevee]

Jeremias Maerki a écrit :
> There's not much else you can do other than to try to handle/work-around
> everything in XSLT. FOP does not have special code to handle languages
> like Chinese. We lack the knowledge set in the project team. Every now
> and then we talk about implementing UAX#14 line breaking but so far
> nobody had the resources to dive into this. Any help is welcome.

OK,
In fact, I haven't find any formatter that does that. XSL Formatter
doesn't support that (said the Antenna House support), no answer yet of
XEP support.
So the only way to do a such hyphenation is to code it myself in FOP. So
maybe I will be involved in that stuff, depending of the work to do.
Can I have more info about the "UAX#14" ?

bye,
Nicolas

> 
> On 06.03.2006 10:48:24 Nicolas Lalevee wrote:
> 
>>Hi everybody,
>>
>>I have succeeded in producing a chinese PDF from an XML document via a
>>XSL transformation.
>>There is a last problem. The professional chinese document should not
>>let a chinese character alone on a line.
>>For instance, I have the sentense "AZERTYUIO." to render in PDF. FOP
>>(with the patch of the bug 36977 for the trunk version), generate a PDF
>>with :
>>AZERTYUI
>>O.
>>
>>And, for chinese people, that's not a well rendered document. The
>>prefered layout is :
>>AZERTYUIO. (the characters have to be compressed)
>>or
>>AZERTYU (the characters have to be expanded)
>>IO.
>>
>>The only way I found to do so is to force the last three characters of a
>>text to be "no-wrap". Here is my XSL template :
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>select="'.'" />
>>>select="'.​'" />
>>
>>
>>
>>>select="'\​'" />
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>keep-together.within-line="always">
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>And that's a not good solution because some ends of line can be missed.
>>In my XML source document, I can have inline formatting properties, like
>>bold or italic, that makes the text sequence shorter than 3, even if the
>>complete sentense contains more than 3 characters.
>>
>>Is there any other way to handle this hyphenation particularity ?
>>
>>Thanks in advance
>>Nicolas
> 
> 
> 
> Jeremias Maerki


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]