Re: charts not rendered on Sun Solaris
As a rule of thumb: Questions which don't require to ask back because there is enough information to work with are more likely to get answered quickly. Unfortunately, that's the case here. You didn't: - say which FOP version you're using (Don't assume everyone remembers from earlier posts which FOP version you use, or looks it up each time). - say what kind of charts these are. Are they PNGs? TIFFs? SVGs? Something else? All that can make a difference. You can save yourself and us time if you put more information in your questions. If I had to guess, I'd say you don't have the graphical environment set up properly on the Solaris machine. Batiks needs that. See: http://xmlgraphics.apache.org/fop/0.94/graphics.html#batik On 07.05.2008 05:44:49 Harshini Madurapperuma wrote: Hi Can anybody give a suggestion to my problem please :( /Harshini -Original Message- From: Harshini Madurapperuma [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 2:24 PM To: fop-users@xmlgraphics.apache.org Subject: Fo:charts not rendered on Sun Solaris Hi all I tried to preview a report(with charts) in a Sun Solaris 10 environment, but the report is not displayed for Preview. But the same report is previewed correctly in this same environment after the chart is removed from the report. The same report is previewed (with charts) without problems when it is running on a Windows machine. Is there a problem to render a chart when run on Sun Solaris 10. Or should I set some parameters in a special way? Your support is greatly appreciated Many thanks in Advance Harshini Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Italic Tahoma
FOP does not yet support synthesized TrueType variant in PDF as described in PDF 1.4, chapter 5.5.2 TrueType Fonts. At the moment, you have to use fonts that have all the bold and italic variants explicitely as font files. Font auto-detection is not enabled by default because it's a relatively new feature and we needed to get some experience with it first. There were some bugs, too. At some point, we can certainly enable that if there's no explicit font configuration. On 06.05.2008 12:26:54 Antti Karanta wrote: Hi! I tried using fo:inline element to produce italic text using Tahoma font. It did not work. Here's what I did: fo:inline font-family=Tahoma font-style=italicitalics/fo:inline FOP said: 6.5.2008 13:08:31 org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'Tahoma,italic,400' not found. Substituting with 'Tahoma,normal,400'. I dug around a bit and found out that Tahoma does not have an italic variant (see e.g. http://help.lockergnome.com/office/Tahoma-italic-ftopict705661.html). So, I tried oblique instead: fo:inline font-family=Tahoma font-style=obliqueitalics/fo:inline FOP said: 6.5.2008 12:16:54 org.apache.fop.fonts.FontInfo notifyFontReplacement WARNING: Font 'Tahoma,oblique,400' not found. Substituting with 'Tahoma,normal,400'. I consulted an XSL-FO reference (Definitive XSL-FO by G. Holman) and it said about font-style attribute: note that italic will match oblique if no italic face is available in the font family, so no surprise that the second try was no better. Changing font-family=Tahoma to font-family=Tahoma,Verdana makes FOP use Verdana's italic, which, at least to my eye looks good enough. But the question is: is there a known way to have italic(ish) Tahoma? E.g. MS Word somehow manages something that looks ok even if Tahoma Italic does not really exist. I suppose it makes it using oblique Tahoma (http://en.wikipedia.org/wiki/Oblique_type) - can FOP be made to perform the same trick? Environment: windows xp sp2, java 1.5.0_15, fop 0.95 beta. -::Antti::- Ps. Naturally in my fop.xconf I have renderers renderer mime=application/pdf fonts auto-detect/ /fonts ... to make this work. BTW, what is the reason font auto-detection is not enabled by default? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SOLVED] Re: Major issue with image loading in FOP 0.95beta
On 06.05.2008 15:25:20 Jean-François El Fouly wrote: Jeremias Maerki a écrit : I've done that now: http://svn.apache.org/viewvc?rev=653704view=rev Jean-Fraçois, please download XG Commons Trunk, build it and switch to it. Then set -Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true (system property). Hopefully, this will change something. Please let me know if it does. Yes, your patch does the trick ! I've built my chapter successfully, then all the chapters of the document and it's OK. Congratulations and thanks very much ! Great, now we only have to figure out what the best variant is for a long-term fix. Now I guess you all have to take a decision whether this patch belong to 0.95 release because it is probably needed in a number of situations... If possible, this will go into 0.95. And my next problem is to find a way to force memory recycling after this long and hefty FOP processing, but until further investigated this is OT ;-) You probably didn't get my hint earlier but with the new image loading framework you should actually get away with lower memory settings. In my tests I have been able to produce PDF with little text and many images with 40MB of VM memory which wasn't possible with 0.94 and earlier. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Problem using Lucida Console font
Hi! My adventures with fonts continue. Now I run into trouble trying to use Lucida Console (in pdf). What I have is this: fo:block space-before.minimum=0.8em space-before.optimum=1em space-before.maximum=1.2em space-after.minimum=0.8em space-after.optimum=1em space-after.maximum=1.2em hyphenate=false wrap-option=no-wrap white-space-collapse=false white-space-treatment=preserve linefeed-treatment=preserve text-align=start font-family='Lucida Console' id=d0e69blah blah/fo:block I also tried font-family=Lucida Console (i.e. without the single quotes) FOP says WARNING: Font 'Lucida Console,normal,400' not found. Substituting with 'any,normal,400'. This is strange since the other fonts in c:\WINDOWS\Fonts directory seem to work ok when referenced (e.g. Tahoma, Verdana). Could there be a problem because the font name has a space in it? Do I have to create a separate font metrics file? If so, why is this necessary for Lucida Console, but not e.g. for Tahoma and Verdana? My environment: win xp sp 2, java 1.5.0_15, fop 0.95beta in my fop.xconf I have renderers renderer mime=application/pdf fonts auto-detect/ /fonts -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
Worked fine for me with and without additional quotes in 0.95beta (same setup as yours except I used Sun JVM 1.5.0_14). Are you sure that your config file gets used? Test file: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; font-family=Lucida Console fo:layout-master-set fo:simple-page-master master-name=A4 page-height=29.7cm page-width=21cm margin=2cm fo:region-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=A4 fo:flow flow-name=xsl-region-body fo:blockHello World!/fo:block /fo:flow /fo:page-sequence /fo:root Config file: ?xml version=1.0 encoding=UTF-8? fop renderers renderer mime=application/pdf fonts auto-detect/ /fonts /renderer /renderers /fop On 07.05.2008 10:11:09 Antti Karanta wrote: Hi! My adventures with fonts continue. Now I run into trouble trying to use Lucida Console (in pdf). What I have is this: fo:block space-before.minimum=0.8em space-before.optimum=1em space-before.maximum=1.2em space-after.minimum=0.8em space-after.optimum=1em space-after.maximum=1.2em hyphenate=false wrap-option=no-wrap white-space-collapse=false white-space-treatment=preserve linefeed-treatment=preserve text-align=start font-family='Lucida Console' id=d0e69blah blah/fo:block I also tried font-family=Lucida Console (i.e. without the single quotes) FOP says WARNING: Font 'Lucida Console,normal,400' not found. Substituting with 'any,normal,400'. This is strange since the other fonts in c:\WINDOWS\Fonts directory seem to work ok when referenced (e.g. Tahoma, Verdana). Could there be a problem because the font name has a space in it? Do I have to create a separate font metrics file? If so, why is this necessary for Lucida Console, but not e.g. for Tahoma and Verdana? My environment: win xp sp 2, java 1.5.0_15, fop 0.95beta in my fop.xconf I have renderers renderer mime=application/pdf fonts auto-detect/ /fonts -::Antti::- Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On May 7, 2008, at 10:11, Antti Karanta wrote: Hi My adventures with fonts continue. Now I run into trouble trying to use Lucida Console (in pdf). What I have is this: fo:block space-before.minimum=0.8em space-before.optimum=1em space-before.maximum=1.2em space-after.minimum=0.8em space- after.optimum=1em space-after.maximum=1.2em hyphenate=false wrap-option=no-wrap white-space-collapse=false white-space- treatment=preserve linefeed-treatment=preserve text- align=start font-family='Lucida Console' id=d0e69blah blah/ fo:block I also tried font-family=Lucida Console (i.e. without the single quotes) FWIW: Both should work. XSL-FO refers to CSS for the definition, and the CSS spec only /recommends/ to use quotes for font-family names with spaces, but FOP should allow and process both variants correctly. FOP says WARNING: Font 'Lucida Console,normal,400' not found. Substituting with 'any,normal,400'. This is strange since the other fonts in c:\WINDOWS\Fonts directory seem to work ok when referenced (e.g. Tahoma, Verdana). Could there be a problem because the font name has a space in it? Very close. IIC, the problem would be that the TTF-file itself contains another font-name than 'Lucida Console'. I seem to remember a similar issue popping up recently (but that was for Type1 fonts). That issue was confirmed to be fixed in 0.95 head (to be released in a couple of weeks). Maybe it also solves your problem...? Can you try to checkout and build FOP 0.95 (*), and see if that helps already? If you don't have them yet: Subversion, a JDK and Apache Ant are needed to do this. If you don't have those tools handy, and you won't ever need them for anything else, then it is probably overkill to set up. In that case, I hope someone out there chimes in to confirm/refute what I mentioned above. I currently have no Windows-box to test on... (*) http://xmlgraphics.apache.org/fop/download.html#source Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On May 7, 2008, at 10:30, Andreas Delmelle wrote: snip / Can you try to checkout and build FOP 0.95 (*), and see if that helps already? If you don't have them yet: Subversion, a JDK and Apache Ant are needed to do this. If you don't have those tools handy, and you won't ever need them for anything else, then it is probably overkill to set up. In that case, I hope someone out there chimes in to confirm/refute what I mentioned above. I currently have no Windows-box to test on... (*) http://xmlgraphics.apache.org/fop/download.html#source Apologies, I overlooked that the 0.95 branch is not referenced on this page (only the 0.95beta tag, which would give you the exact same version you're working with now) If you still need it, the URL to use with SVN for 0.95 head: http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_95 Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: charts not rendered on Sun Solaris
Hi Sorry about it. I'm using a JfreeChart a third party library to generate charts. Then the outcome to a XSL will look like this: fo:table-cell border-style=none white-space-collapse=false vldt-object=FoTableCell element-id=old test_18 fo:block vldt-object=MultiBarChart fo:instream-foreign-object xsl:copy-of select=chart:multiBarChart(null,tns:OS_USER, tns:SESSION_ID, '', '', 'Arial', '12' ,0,-12566464, '', 'Arial', '18' ,1,-12566464, 'BOTTOM', 'Arial','12','0', 0, 0, -43691, -11184641, -11141291, -171, -43521, -11141121, -20561, -8355712, -4194304, -16777024, 5.8208327,17.0)/ /fo:instream-foreign-object /fo:block /fo:table-cell And my FOP version is quite old it's 0.20.5. And difficult to upgrade it to a latest version for the moment. Regards Many thanks in Advance Harshini -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 12:22 PM To: fop-users@xmlgraphics.apache.org Subject: Re: charts not rendered on Sun Solaris As a rule of thumb: Questions which don't require to ask back because there is enough information to work with are more likely to get answered quickly. Unfortunately, that's the case here. You didn't: - say which FOP version you're using (Don't assume everyone remembers from earlier posts which FOP version you use, or looks it up each time). - say what kind of charts these are. Are they PNGs? TIFFs? SVGs? Something else? All that can make a difference. You can save yourself and us time if you put more information in your questions. If I had to guess, I'd say you don't have the graphical environment set up properly on the Solaris machine. Batiks needs that. See: http://xmlgraphics.apache.org/fop/0.94/graphics.html#batik On 07.05.2008 05:44:49 Harshini Madurapperuma wrote: Hi Can anybody give a suggestion to my problem please :( /Harshini -Original Message- From: Harshini Madurapperuma [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 2:24 PM To: fop-users@xmlgraphics.apache.org Subject: Fo:charts not rendered on Sun Solaris Hi all I tried to preview a report(with charts) in a Sun Solaris 10 environment, but the report is not displayed for Preview. But the same report is previewed correctly in this same environment after the chart is removed from the report. The same report is previewed (with charts) without problems when it is running on a Windows machine. Is there a problem to render a chart when run on Sun Solaris 10. Or should I set some parameters in a special way? Your support is greatly appreciated Many thanks in Advance Harshini Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- CONFIDENTIALITY AND DISCLAIMER NOTICE This e-mail, including any attachments, is confidential and intended only for the addressee. If you are not the intended recipient, please notify us immediately and delete this e-mail from your system. Any use or disclosure of the information contained herein is strictly prohibited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: charts not rendered on Sun Solaris
I have never used JFreeChart. I assume the chart:multiBarChart function generates SVG since you embed it in an instream-foreign-object. Even for FOP 0.20.5, the note about the graphical environment needed by Batik applies equally: http://xmlgraphics.apache.org/fop/0.94/graphics.html#batik So my initial suspicion is probably correct. Please make sure that your Java application has a proper graphical environment to work with. On 07.05.2008 11:20:03 Harshini Madurapperuma wrote: Hi Sorry about it. I'm using a JfreeChart a third party library to generate charts. Then the outcome to a XSL will look like this: fo:table-cell border-style=none white-space-collapse=false vldt-object=FoTableCell element-id=old test_18 fo:block vldt-object=MultiBarChart fo:instream-foreign-object xsl:copy-of select=chart:multiBarChart(null,tns:OS_USER, tns:SESSION_ID, '', '', 'Arial', '12' ,0,-12566464, '', 'Arial', '18' ,1,-12566464, 'BOTTOM', 'Arial','12','0', 0, 0, -43691, -11184641, -11141291, -171, -43521, -11141121, -20561, -8355712, -4194304, -16777024, 5.8208327,17.0)/ /fo:instream-foreign-object /fo:block /fo:table-cell And my FOP version is quite old it's 0.20.5. And difficult to upgrade it to a latest version for the moment. Regards Many thanks in Advance Harshini -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 07, 2008 12:22 PM To: fop-users@xmlgraphics.apache.org Subject: Re: charts not rendered on Sun Solaris As a rule of thumb: Questions which don't require to ask back because there is enough information to work with are more likely to get answered quickly. Unfortunately, that's the case here. You didn't: - say which FOP version you're using (Don't assume everyone remembers from earlier posts which FOP version you use, or looks it up each time). - say what kind of charts these are. Are they PNGs? TIFFs? SVGs? Something else? All that can make a difference. You can save yourself and us time if you put more information in your questions. If I had to guess, I'd say you don't have the graphical environment set up properly on the Solaris machine. Batiks needs that. See: http://xmlgraphics.apache.org/fop/0.94/graphics.html#batik On 07.05.2008 05:44:49 Harshini Madurapperuma wrote: Hi Can anybody give a suggestion to my problem please :( /Harshini -Original Message- From: Harshini Madurapperuma [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 06, 2008 2:24 PM To: fop-users@xmlgraphics.apache.org Subject: Fo:charts not rendered on Sun Solaris Hi all I tried to preview a report(with charts) in a Sun Solaris 10 environment, but the report is not displayed for Preview. But the same report is previewed correctly in this same environment after the chart is removed from the report. The same report is previewed (with charts) without problems when it is running on a Windows machine. Is there a problem to render a chart when run on Sun Solaris 10. Or should I set some parameters in a special way? Your support is greatly appreciated Many thanks in Advance Harshini Jeremias Maerki Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On Wed, 07 May 2008 11:30:32 +0300, Jeremias Maerki [EMAIL PROTECTED] wrote: Worked fine for me with and without additional quotes in 0.95beta (same setup as yours except I used Sun JVM 1.5.0_14). Are you sure that your config file gets used? Turns out I had messed up my PATH and was using 0.94 when I thought I was using 0.95 beta. Everything works just fine w/ 0.95 beta. My mistake, sorry about the trouble, thanks for the help! -::Antti::- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Changing orientation with fo:block-container holding a table
Greetings to all! I am using fop v 0.94 on a Windows XP box. I have the task to transform some XML into XSL-FO and part of that XML is actually xhtml containing tables. Some of those tables are wider than a standard A4 page, so I wanted to rotate them using fo:block-container reference-orientation=90 /. But I stumbled upon a problem that cannot find a solution for. The table is rotated very nicely but the problem occurs if the table cannot fit in the container. The rendering of the table continues to the end of the page (right side in the 90 case) and after that it is continued on the next page. What I think is a bug or misuse by me is that the transition to the next page should occur when the block-container ends. The fact that the table header is re-rendered at the point where the correct transition should occur makes me speculate that this might be a bug. Can you please refer to any solutions to this problem? And also should this also be posted to fop-dev mailing list? Regards, Alexander zzz-rotate.fo Description: Binary data zzz.pdf Description: Adobe PDF document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing orientation with fo:block-container holding a table
On May 7, 2008, at 17:04, Alexander Stamenov wrote: Hi The table is rotated very nicely but the problem occurs if the table cannot fit in the container. The rendering of the table continues to the end of the page (right side in the 90 case) and after that it is continued on the next page. What I think is a bug or misuse by me is that the transition to the next page should occur when the block-container ends. The fact that the table header is re-rendered at the point where the correct transition should occur makes me speculate that this might be a bug. This looks buggy indeed, but I'm not 100% certain what the bug is exactly (or even if there is one). The more I think about, the more correct the behavior seems to be. What I found out so far, is that it works if you specify the reference-orientation on the region-body, and leave it off the block- container. Now, it seems a bit problematic IMO, since: - the block-container has no specified height = auto-height, which means the total height should be equal to the content-height - that height will only increase in case the block-container's content overflows the available space in block-progression-direction Contrary to what one could assume (and what I once believed as well), the reference-orientation property has no influence on the correspondence mapping. This means that, even though you have rotated the block-container, inline-progression-dimension will still correspond to width. This seems to work OK: the block-container is 16cm wide. BUT: The available space in block-progression-dimension for the table would, still be the reference-area's block-progression-dimension (the block-container's height, not the page-width) [?] At least this interpretation is reflected in 0.95, where I don't see the header appear anymore. If not rotated, then the block-container can grow to fit the table on one page, so I see no page-break. OTOH, if I switch to 16cm block-progression dimension, with a rotated region-body then the block-container also does not break, where I'd expect it to... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Changing orientation with fo:block-container holding a table
On May 7, 2008, at 18:24, Andreas Delmelle wrote: Just realized that it came out a bit wrong: This looks buggy indeed, but I'm not 100% certain what the bug is exactly (or even if there is one). The more I think about, the more correct the behavior seems to be. I did not mean the 'behavior', but FOP's interpretation. On top of that: BUT: The available space in block-progression-dimension for the table would, still be the reference-area's block-progression- dimension (the block-container's height, not the page-width) [?] Right now, you have situation of overflow, rather than a break (with 0.95). As far as I understand, 0.94 was wrong to break the table there. The block-container overflows the region-body in inline-progression- dimension, hence no page-break. Strange as it may seem, you would only get a page-break if the inline- progression-dimension of the block-container exceeds the available space in block-progression-dimension. At least this interpretation is reflected in 0.95, where I don't see the header appear anymore. If not rotated, then the block-container can grow to fit the table on one page, so I see no page-break. OTOH, if I switch to 16cm block-progression dimension, with a rotated region-body then the block-container also does not break, where I'd expect it to... I think I made an interpretation error here. Rotating the region- body, also does not suddenly swap bpd and ipd. We will only get a page-break if the flow exceeds the available space in block-progression-direction (the page-height), but overflow in inline-progression-direction, hence no break. Even so, when you specify a bpd on the block-container into which the entire table fits, without breaks, then the block-container will not be broken. Only its contents will overflow the available page-height (read: with explicit bpd, even rotating the entire page does not help). Maybe there's something clever you can pull off with nested block- containers. Another idea may be to give the region-body less height, but that would not work if the block-container appears among other content. :/ In any case, the only way you can influence ipd-bpd direction relative to the flow, is to switch to a different writing-mode, but FOP is currently still severely limited in this area. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
Andreas Delmelle andreas.delmelle at telenet.be writes: On May 7, 2008, at 10:30, Andreas Delmelle wrote: snip / Can you try to checkout and build FOP 0.95 (*), and see if that helps already? snip/ If you still need it, the URL to use with SVN for 0.95 head: http://svn.apache.org/repos/asf/xmlgraphics/fop/branches/fop-0_95 Cheers Andreas I am on Linux (Kubuntu Gutsy Gibbon (7.10?)). Auto-detection of fonts does not work most of the time. For example, I cannot use Bodoni (Type 1 font - the download page says that it is shareware, but neither the site nor the ZIP file says who should be paid). I downloaded the font at http://www.winsite.com/bin/Info?50017011. Scribus lets me embed this font in a PDF, and Scribus itself says that it is strict about the fonts that it allows to be embedded, so I assume that nothing is wrong with the font. 'fc-list Bodoni' gives: Bodoni:style=Bold Bodoni:style=Normal-Italic Bodoni:style=Normal 'ls /usr/local/share/fonts/bodoni*' gives: /usr/local/share/fonts/bodoni.afm /usr/local/share/fonts/bodonii.pfb /usr/local/share/fonts/bodonib.afm /usr/local/share/fonts/bodonii.pfm /usr/local/share/fonts/bodonib.pfb /usr/local/share/fonts/bodoni.pfb /usr/local/share/fonts/bodonib.pfm /usr/local/share/fonts/bodoni.pfm /usr/local/share/fonts/bodonii.afm AFM, PFM and PFB files are all present. However fop-trunk svn (653186, 2008-05-03) and fop-0.95beta svn (653537, 2008-05-05) both say: WARNING: Font 'Bodoni,normal,400' not found. Substituting with 'any,normal,400'. I used the same FO and fop.xconf that was posted. I noticed that fop printed a lot of warnings like: May 7, 2008 2:05:22 PM org.apache.fop.fonts.truetype.TTFFile determineAscDesc WARNING: Ascender and descender together are larger than the em box. This could lead to a wrong baseline placement in Apache FOP. and May 7, 2008 2:05:35 PM org.apache.fop.fonts.truetype.TTFFile guessVerticalMetricsFromGlyphBBox WARNING: xHeight value could not be determined. The font may not work as expected. May 7, 2008 2:05:35 PM org.apache.fop.fonts.type1.PFMFile loadExtMetrics WARNING: Size of extension block was expected to be 52 bytes, but was 0 bytes. The messages do not say which fonts cause the warnings. I do not know if it matters. By the way, I have found a few Type 1 fonts that fop recognises, but no TrueType fonts so far. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using Lucida Console font
On May 7, 2008, at 22:16, John Brown wrote: Hi John I am on Linux (Kubuntu Gutsy Gibbon (7.10?)). Auto-detection of fonts does not work most of the time. Judging from the info, it's not so much the font-detection that isn't working, but rather, it points to issues with the loading/parsing of the font-files. The AFM parser is a relatively new addition IIC, so could be that there are still some hiccups in there. Personally, I have seen issues with the TrueType fonts for Mac, where the Windows variant is perfectly parsed. I suspect this is due to the fact that the devs working on the font- loading code did most of their work on a Windows box and had no Mac TTFs available to test. On another note: which JVM are you using? One thing I did notice when I once looked closer at the TTFLoader is a lot of bit-shifting. It would only require a small quirk in the JVM in that respect to make the loader parse the file completely wrong... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
