Bug with tables and footers?
Hi, I think I found a little bug with when you have a table and a footer, having the body content overlap the footer. However, I'm not sure if this really counts as a bug, since I actually have the rowspan = 3 when there's only one row in the table. Don't really need it fixed or anything, just letting you know. Anyways, the code is below: http://www.w3.org/1999/XSL/Format";> This is the footer. This is the footer. This is the footer. This is the footer. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. How can we get the knowledge to the right place? This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This is the body text. This
Re: preliminary report on thesis and memory use
Charles Griswold wrote: The only issue we've encountered is a significant memory leak on successive reports. Initial testing seems to indicate a loss of about 100m with each execution. I suspect this is the image cache. Try resetting the cache between executions. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Bug is filed against SAXON including patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1483350&group_id=29872&atid=397617 Let's see what happens. On 07.05.2006 15:06:10 Florent Georges wrote: > Jeremias Maerki wrote: > > > No, I did not, but I think the whole thing will be resolved > > more quickly if I write the necessary patch for SAXON and > > submit that with the error description. But first, I want > > to look at the PDF size problem. > > Ok, thanks a lot. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filesize of created PDFs
Should be fixed now in FOP Trunk: http://svn.apache.org/viewcvs?rev=404759&view=rev Instead of embedding a smaller sRGB profile, I chose not to embed an sRGB profile at all which should match the behaviour from before the color profile handling was changed. Non-default ICC profiles will still be embedded. On 28.04.2006 10:03:47 Jeremias Maerki wrote: > Interesting. Didn't notice that before. Here's what happens: > > The PNG is decoded by the PNG codec in XML Graphics Commons. Even if the > PNG does not contain an explicit ICC color profile, the default sRGB > color profile is returned because it's a Java default. The problem with > Java's sRGB profile is that it's about 100KB in size even though there > are sRGB profiles which are merely 4KB in size (we include one for PDF/A > support). Currently FOP simply includes the ICC color profile if one is > returned. In the case of sRGB this is probably not necessary or we might > at least replace Java's profile with the embedded smaller one. The > result for ICC-aware readers should be the same. > > To fix this, code needs to be added to identify Java's default sRGB > profile and to ignore/replace it when output files (not only PDF!) are > written. > > On 28.04.2006 08:55:43 news wrote: > > Hello List, > > > > If I include a grafic into my PDF (in this example a PNG) the resulting PDF > > filesize has an enormous diffenrence between FOP025 and FOP092 beta. When > > rendered with 0.25 the file's size is about 8kb. The same FO file results in > > an 108kb(!) big PDF file when rendered with 0.92 > > beta! > > If I does'nt include a picture the filesize is about equal. > > > > Both, FOP025 and FOP092 got the "jai_codec.jar" and "jai_core.jar" in there > > lib folder and FOPs classpath. > > > > How can that happen? > > I m storing the resulting PDFs into a database. A improvment of the > > resulting filesizes of factor 10 and over is really bad for me :( Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Asian fonts in pdfs
On Sun, 07 May 2006 12:02:37 +0200 Jeremias Maerki <[EMAIL PROTECTED]> wrote: > If you look at [1] you'll see that Hangul syllables are not covered by > the DejaVu font. That's why they don't appear. You'll need to find > another font. Ah, thanks very much for this! I'll keep trying with some other fonts. I tried arphic-uming for Chinese, after being told that this supported Chinese characters. However fop crashed with a message like this: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space I'm pretty unlucky with fop! > Concerning the "noisy output" I'd recommend you take a closer look at > the warning messages. You'll find they are quite informative. There > are a lot of table-rows with height="14pt" in your FO file. 14pt is > too little for a 12pt font with line-height="1.2" (the default). > Either remove the height property or adjust it to at least 14.4pt > (=12 * 1.2). Yeah I read the messages and saw an explanation of it on the fop wiki. But at the moment I don't know how to modify the xsl I'm using to get rid of this, I'll look into it, and possibly ask another mailing list how to do this. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Jeremias Maerki wrote: > No, I did not, but I think the whole thing will be resolved > more quickly if I write the necessary patch for SAXON and > submit that with the error description. But first, I want > to look at the PDF size problem. Ok, thanks a lot. Regards, --drkm ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendez-vous sur http://fr.yahoo.com/set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
No, I did not, but I think the whole thing will be resolved more quickly if I write the necessary patch for SAXON and submit that with the error description. But first, I want to look at the PDF size problem. On 07.05.2006 14:39:43 Florent Georges wrote: > Jeremias Maerki wrote: > > Hi Jeremias > > > As I suspected, it's a bug in SAXON 8.7.1. > > net.sf.saxon.dom.DOMWriter.attribute() does not convert > > empty Strings (for "no namespace") to null when it calls > > element.setAttributeNS(). > > > Of course, one could argue who exactly is at fault here, > > SAXON or Batik. IMO, Batik did well with the fix to > > accept an empty String and null, but SAXON shouldn't send > > an empty String in the first place. > > > I'd file a bug in the SAXON project. > > Did you report the bug? I can't find it in the Saxon bug > tracker, and Michael doesn't seem to be aware of it. > > I can do it if you want, but while I understand the bug > description, I don't have intimate knowledge of the > different elements involved here. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: REGRESSION: embedded SVG support in 0.92beta compared to 0.91beta
Jeremias Maerki wrote: Hi Jeremias > As I suspected, it's a bug in SAXON 8.7.1. > net.sf.saxon.dom.DOMWriter.attribute() does not convert > empty Strings (for "no namespace") to null when it calls > element.setAttributeNS(). > Of course, one could argue who exactly is at fault here, > SAXON or Batik. IMO, Batik did well with the fix to > accept an empty String and null, but SAXON shouldn't send > an empty String in the first place. > I'd file a bug in the SAXON project. Did you report the bug? I can't find it in the Saxon bug tracker, and Michael doesn't seem to be aware of it. I can do it if you want, but while I understand the bug description, I don't have intimate knowledge of the different elements involved here. Regards, --drkm ___ Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Rendez-vous sur http://fr.yahoo.com/set - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Asian fonts in pdfs
If those documents use Unicode charsets, a possible solution is to embed ttf font contains needed charsets into PDF. I am using DFSG-free version of "kochi" font family for asian languages. To embed fonts first prepare font map xml using provided with fop tool: fop-ttfreader kochi-gothic.ttf kochi-gothic.xml Create config file with font map settings. Here my config file cnf.xml: strokeSVGText false Then when you want to "fop": fop -c cnf.xml -fo data.fo -pdf document.pdf On Saturday 06 May 2006 18:48 pm, Matthew East wrote: > Hi all, > > I'm trying to build (using fop 0.20-5) some pdfs of some guides which are > in Asian languages (Taiwanese, Chinese, Korean etc) and the resulting pdfs > don't show any of the characters, just hash symbols. Does anyone know how I > can improve this situation? > > I've put an example .fo file and the resulting .pdf file at this address: > > http://mdke.org/ubuntu/fop/ > > Hope you can help! > > Thanks, Matt > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Regards, Lev T. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Asian fonts in pdfs
If you look at [1] you'll see that Hangul syllables are not covered by the DejaVu font. That's why they don't appear. You'll need to find another font. [1] http://svn.sourceforge.net/viewcvs.cgi/*checkout*/dejavu/trunk/dejavu-fonts/unicover.txt Concerning the "noisy output" I'd recommend you take a closer look at the warning messages. You'll find they are quite informative. There are a lot of table-rows with height="14pt" in your FO file. 14pt is too little for a 12pt font with line-height="1.2" (the default). Either remove the height property or adjust it to at least 14.4pt (=12 * 1.2). Note to FOP committers: Interestingly, the DejaVu font might actually meet our needs license-wise if we want a set of fonts we can redistribute. We'd only have to check with legal since the license is not standard BSD. The drawback: The fonts are quite large (5 MB all together). On 07.05.2006 01:17:02 Matthew East wrote: > Thomas Schraitle web.de> writes: > > On Saturday 06 May 2006 19:20, Matthew East wrote: > > > [...] > > > > 1. Check the font if it contains Korean characters > > > > > > I don't really understand much about fonts, but on my system, if I view > > > the "fo" file in an editor and set my editor to display serif fonts, > > > all the korean characters appear fine. > > > > I think that are two different things. As far as I know, FOP knows only > > those fonts that are registered in its configuration file. Therefor you > > have to configure the fonts first that you want to use in your FO file. > > Otherwise it won't work. See [1] for more information about fonts in FOP. > > Right, I did some more playing around with this. This time, I used fop > 0.92beta > and got some font metrics files from the "dejavu-serif" truetype font which I > embedded in the pdf. I'm reliably informed that this carries the relevant > Asian > fonts. However, although the font seems to have been successfully embedded, > the > correct characters are still not showing. I've uploaded the fo and resultant > pdf > here: > > http://mdke.org/ubuntu/fop/0.92beta/ > > The output of building the pdf was extremely noisy, although I don't think the > noise has anything to do with the problem which is the subject of this thread. > In any case, I've posted them here: http://pastebin.com/702716 > > Any more ideas? Lemme know if you need any more information! Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
