Fop and line-overruns using Japanese fonts

[Brad Smith]

Hello all,

I have some documents with Japanese text that have been presenting
some very frustrating problems. When I render them using fop, in
several places long lines with no spaces (as is often the case with
such languages) spill over the edge of the page. Some searching online
and on this list found that this is a known issue and I read a
suggestion to insert a zero-width space (\u200B, I assume) between
each character as a fix. However, when I do this there is too little
space between characters when I render, such that the glyphs all
overlap one another. In some cases, they are also offset far to the
left so that they off the left edge of the page instead of the right.
I tried using a hair-space (\u200A) instead and had similar results.

Does anyone have an alternate workaround? I'm using fop 0.93.

--Brad

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

RE: URIResolver for svg

[Peter]

> So, my tip is to concentrate on Batik first, and on FOP second.

Thanks. So I did go a bit into Batik and actually asked for some design
background of Batik's uri resolution mechanism (have not received a reply
just yet).  From the bit I have learned though, I am somewhat concerned I
might be opening Pandora's box, and while that does not worry me too much, I
don't really have the time right now to wade into that.

So, only because it might help someone else one day - when I realized
URIResolver is an interface and Batik requires class(es) extending a given
base class I decided to come up with something like 

class MyResolver extends 
  ParsedURLDefaultProtocolHandler 
  implements URIResolver {
...
}

I know, they don't come much uglier, but at least it keeps the mess isolated
and allows me to move forward.

Thanks for your help and explanations!

Peter


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

RE: URIResolver for svg

[Peter]

> I imagine in the longer term the basic URI resolution should maybe go in
> Batik with a specialisation of this class in FOP.  What does everybody
> else think?

Having started this discussion I guess it is no more than polite to at least
reply with something. Unfortunately I don't have much to say on this. It
does seem correct that Batik's "uri resolution" requirements are more
"granular" than those of FOP and therefore your proposes specialization
makes sense. On the other hand, uri resolution seems a common enough problem
to justify putting it in the commons "project".


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

Re: Re: fop.jar, Service-registration mechanism, one-jar problem

[b . ohnsorg]

Thanks for the fast and extensive replies. I'll have a look at it and retry. 
Maybe a JavaDoc-comment makes it a bit easier being new to «funny things with 
service registration that's not so funny at all».
- original Nachricht 

Betreff: Re: fop.jar, Service-registration mechanism, one-jar problem
Gesendet: Fr 27 Apr 2007 08:50:57 CEST
Von: "Jeremias Maerki"<[EMAIL PROTECTED]>

> Plus, you may need to merge some text files inside /META-INF/services if
> you merge multiple JARs which may have files with the same name.
> 
> BTW, FOP doesn't do "funny things" concerning renderer registration.
> This is a properly documented facility offered through Java. See here:
> http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service%20Provider
> Many packages use that facility including: ImageIO, javax.sound, Apache
> Batik, Apache Xalan-J and many more.
> 
> 
> On 27.04.2007 02:10:20 Daniel Noll wrote:
> > [EMAIL PROTECTED] wrote:
> > > Now FOP does a funny thing with renderer-registration and I don't see
> > > the use for it. Instead of doing a sort of init process like:
> > > 
> > > - create map
> >  > - register internal classes with MIMEs
> >  > - handover map to plugin concept
> > > 
> > > you do something like "read entries from file fop.jar and register if
> > > instance of some sort of abstract renderer".
> > 
> > It sounds like you might have just forgotten to put the content of 
> > fop.jar's /META-INF directory into your own jar file.
> > 
> > Daniel
> > 
> 
> 
> 
> Jeremias Maerki
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

--- original Nachricht Ende 










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

RE: Generate Black and White PDF's

[Pascal Sancho]

Hi,

You should have a look on post-processing tools (see [1]).

I've red on i-text pages [2] that there is a GrayColor class that could help 
you, but not sure.

HTH,

Pascal

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

[2] http://itext.ugent.be/library/api/com/lowagie/text/pdf/GrayColor.html

> -Message d'origine-
> De : Matthias Müller [mailto:[EMAIL PROTECTED] 
> Envoyé : vendredi 20 avril 2007 13:49
> À : fop-users@xmlgraphics.apache.org
> Objet : AW: Generate Black and White PDF's
> 
> hi again ;-)
> 
> Ok, maybe i didn't expressed my needs correctly.
> At the moment i generate PDF files using FOP. This PDF files 
> are colored. 
> What i need now is a way to tell my FOP Serializer to make 
> the same output in gray scales, WITHOUT changing the color 
> properties of each colored block. 
> Got Me ;-)
> 
> - Ursprüngliche Mail 
> Von: mahmoudi ould abdel vetah <[EMAIL PROTECTED]>
> An: fop-users@xmlgraphics.apache.org
> 
> hi,
>  
> ah, ok yes! you have just to choose which parts of document 
> you need to be colored by using basic FO properties like 
> "color" 
> (http://xmlgraphics.apache.org/fop/compliance.html#fo-property-color )
>  
> i don't know if i undestoud your need.
>  
> i hope this helps.
>  
> ps : generally, if you can make something by using fop 
> directly, you can make it when fop is used with cocoon.
> 
>  
> 2007/4/20, Matthias Müller <[EMAIL PROTECTED]>: 
> 
>   hi,
>   
>   I have to generate two version of each document i 
> transform with FOP to PDF.
>   - a colored version
>   - and a version in gray scales (black and white) 
>   
>   - Ursprüngliche Mail 
>   Von: mahmoudi ould abdel vetah < [EMAIL PROTECTED] 
>  >
>   An: fop-users@xmlgraphics.apache.org
>   
>   hello,
>
>   how do you meen by "blanck" and "white" pdf?
>
>   mahmou.


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