DO NOT REPLY [Bug 39560] - Null Pointer Exception
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39560. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39560 --- Additional Comments From [EMAIL PROTECTED] 2006-05-16 07:07 --- Created an attachment (id=18294) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=18294action=view) FO-Input not converted by FOP 0.92 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Font names in FOP 0.92 beta
in FOP 0.92 beta spaces in font names are deleted and then it doesn't match with the original font names (like 'Agfa Rotis Sans Serif', it is handled as AgfaRotisSansSerif). If you change the configuration file 'userconfig.xml using font names without spaces it doesn't match with the Windows font names. When you work with Altova style vision you can't display the preview with the correct font.
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
Some background on my latest change. I found out that certain TrueType fonts were off vertically inside their line area. It turned out it has to do with different interpretations of the ascender and descender values which are part of font metrics and which FOP uses to determine the baseline placement. FOP currently works with the assumption that the ascender+descender fit into the em box. However, in some TrueType fonts the ascender is sometimes given as the maximum elevation of a font which can go way beyond the em box. BTW, this is always true for Java2D/AWT which makes determining the baseline difficult. I've recently implemented similar hacks in the AWT font metrics adapter which I'll commit shortly. You can see the effect of rev 406917 here: http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk.before.pdf http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk.after.pdf The second and third lines are painted using TrueType fonts, the first is a base 14 font and the last a Type 1 font. IMO, my change is an improvement but not a clean fix. I think TrueType has better information on the baseline somewhere (havn't found it, yet). I didn't look closer into the cases where multiple accents are stacked on a glyph. That's basically the reason why the fonts can go beyond the em box. At some point we may need to revisit our model of line building to accomodate these glyphs. I guess I have to buy a book about typography one day... :-) On 16.05.2006 13:45:01 jeremias wrote: Author: jeremias Date: Tue May 16 04:44:57 2006 New Revision: 406917 URL: http://svn.apache.org/viewcvs?rev=406917view=rev Log: Improved baseline detection in TTFReader for TrueType fonts. Ascender and descender values were sometimes not in line with FOP's expectations. Changed some log output from debug to trace level. Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFile.java xmlgraphics/fop/trunk/status.xml snip/ Jeremias Maerki
Re: Font names in FOP 0.92 beta
I recently found that FOP currently does not properly parse the font-family property as specified in the XSL spec [1]. However, it says that you can quote the font names. Maybe that helps you already. I don't think anyone has paid much attention to the font family names in use. It's also important to note that in certain cases spaces are not permitted in font names. So, if the above trick doesn't help it would be good if you could lay out the details of your problem in a more detailed fashion. I don't know about Altova style vision so you'll have to dive in yourself to help solve the problem. [1] http://www.w3.org/TR/xsl11/#font-family On 16.05.2006 09:28:21 Reimund Paetz wrote: in FOP 0.92 beta spaces in font names are deleted and then it doesn't match with the original font names (like 'Agfa Rotis Sans Serif', it is handled as AgfaRotisSansSerif). If you change the configuration file 'userconfig.xml using font names without spaces it doesn't match with the Windows font names. When you work with Altova style vision you can't display the preview with the correct font. Jeremias Maerki
Re: DejaVu TrueType fonts for use in Apache FOP
Cliff's answer: Yes -- as you suspect, this license fits the definition of Category A, since it doesn't place restrictions on independent works that use it or the licensing of larger works, nor does it have any reciprocity provisions. It looks like X.Net with some Artistic tendencies. So we're free to use the DejaVu fonts. Good news! On 07.05.2006 13:19:36 Jeremias Maerki wrote: Cliff, I'd like to get some feedback on the license for the DejaVu TrueType font set: http://dejavu.sourceforge.net The DejaVu fonts are derived from the BitStream Vera fonts. Here's the content of the LICENSE file in the DejaVu 2.5 distribution: Fonts are (c) Bitstream (see below). DejaVu changes are in public domain. Bitstream Vera Fonts Copyright -- Copyright (c) 2003 by Bitstream, Inc. All Rights Reserved. Bitstream Vera is a trademark of Bitstream, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of the fonts accompanying this license (Fonts) and associated documentation files (the Font Software), to reproduce and distribute the Font Software, including without limitation the rights to use, copy, merge, publish, distribute, and/or sell copies of the Font Software, and to permit persons to whom the Font Software is furnished to do so, subject to the following conditions: The above copyright and trademark notices and this permission notice shall be included in all copies of one or more of the Font Software typefaces. The Font Software may be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may be modified and additional glyphs or characters may be added to the Fonts, only if the fonts are renamed to names not containing either the words Bitstream or the word Vera. This License becomes null and void to the extent applicable to Fonts or Font Software that has been modified and is distributed under the Bitstream Vera names. The Font Software may be sold as part of a larger software package but no copy of one or more of the Font Software typefaces may be sold by itself. THE FONT SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL BITSTREAM OR THE GNOME FOUNDATION BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM OTHER DEALINGS IN THE FONT SOFTWARE. Except as contained in this notice, the names of Gnome, the Gnome Foundation, and Bitstream Inc., shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Font Software without prior written authorization from the Gnome Foundation or Bitstream Inc., respectively. For further information, contact: fonts at gnome dot org. $Id: LICENSE 23 2004-08-14 15:50:46Z src $ In essence it seems to be a derivation of the X.Net License. The word sublicense seems to have been removed and a few things added. But as far as I understand the license text (and IANAL and English is not my primary language), I think the license should match Category A. I'd like to request confirmation that we can use these fonts (in binary) within Apache FOP (in SVN and maybe to be bundled in our distributions). Thanks a lot! Jeremias Maerki Jeremias Maerki
Re: svn commit: r406917 - in /xmlgraphics/fop/trunk: src/java/org/apache/fop/fonts/truetype/TTFFile.java status.xml
On Tuesday 16 May 2006 19:58, Jeremias Maerki wrote: Some background on my latest change. I found out that certain TrueType fonts were off vertically inside their line area. It turned out it has to do with different interpretations of the ascender and descender values which are part of font metrics and which FOP uses to determine the baseline placement. FOP currently works with the assumption that the ascender+descender fit into the em box. However, in some TrueType fonts the ascender is sometimes given as the maximum elevation of a font which can go way beyond the em box. BTW, this is always true for Java2D/AWT which makes determining the baseline difficult. I've recently implemented similar hacks in the AWT font metrics adapter which I'll commit shortly. You can see the effect of rev 406917 here: http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk .before.pdf http://people.apache.org/~jeremias/fop/font-metrics-sandbox.fop.trunk .after.pdf The second and third lines are painted using TrueType fonts, the first is a base 14 font and the last a Type 1 font. IMO, my change is an improvement but not a clean fix. I think TrueType has better information on the baseline somewhere (havn't found it, yet). I didn't look closer into the cases where multiple accents are stacked on a glyph. That's basically the reason why the fonts can go beyond the em box. At some point we may need to revisit our model of line building to accomodate these glyphs. I guess I have to buy a book about typography one day... :-) Your fix triggered me looking into the specs and some actual ttf files and I can't make proper sense of it all as well. The whole vertical font metrics area seem to be quite messy, see for example: http://typophile.com/wiki/Vertical%20Metrics%20How-To I don't know anything about LaTeX. Does it understand TrueType fonts? If so would it be worthwhile to check its source code? Also do we know what Foray Fonts does? Until someone comes up with a better (cleaner?) solution to determine the actual baseline position for a given truetype / opentype font your patch looks good to me. snip/ Jeremias Maerki Manuel
