To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101566
------- Additional comments from [email protected] Tue May 5 12:55:18 +0000 2009 ------- So: a) In windows the font metric width is taken as pMetric->mnWidth = static_cast<int>( mfFontScale * aWinMetric.tmAveCharWidth ); http://msdn.microsoft.com/en-us/library/dd145132%28VS.85%29.aspx " tmAveCharWidth Specifies the average width of characters in the font (generally defined as the width of the letter x ). This value does not include the overhang required for bold or italic characters. " I believe this is generally extracted from the xAvgCharWidth field if there is one in the font, i.e. http://www.microsoft.com/typography/OTSpec/os2.htm#acw " xAvgCharWidth Format: 2-byte signed short Units: Pels / em units Title: Average weighted escapement. Description: The Average Character Width parameter specifies the arithmetic average of the escapement (width) of all non-zero width glyphs in the font. Comments: The value for xAvgCharWidth is calculated by obtaining the arithmetic average of the width of all non-zero width glyphs in the font. " and maybe calculated if not there as http://blogs.msdn.com/michkap/archive/2007/08/16/4421328.aspx " there has for a long time been kind of a hack built in to a lot of East Asian fonts whereby the metrics behind tmAveCharWidth were not based on every character and dividing by the total number of them. Instead, it was being calculated by averaging all of the non-ideographic characters. " b) In the old X font system we're doing... i.e. taking the *maximum* width of glyphs in that font pCharStruct->width = std::max( pMaxBounds->width, pCharStruct->width ); c) While in the freetype based system we're doing... mnWidth = rFSD.mnWidth; if( !mnWidth ) mnWidth = rFSD.mnHeight; i.e. the default is a width equal to the height. So three different calculations for the same field I think :-( Stuff generally works out ok because we seem to only want to know the metric width of a font as a value against which we can smuggle condensed/expanded fonts as a scaled value of the font metric width so it all works out ok when sticking within the same calculation system Where stuff breaks down though is in the .wmf import and export, where we have in WMFWriter::WMFRecord_CreateFontIndirect... if ( !rFont.GetSize().Width() ) { VirtualDevice aDev; FontMetric aMetric( aDev.GetFontMetric( rFont ) ); WriteHeightWidth(Size(aMetric.GetWidth(),-rFont.GetSize().Height())); } else WriteHeightWidth(Size(rFont.GetSize().Width(),-rFont.GetSize().Height())); i.e. we get the metrics and write an explicit value for the width. When we reload this document on a different platform we're going to have a different scaling factor for condensation/expansion than expected and it looks crud. As a quick-fix for the most common case of no unusual scaling, we can tweak the wmf exporter to not write *any* width value if there isn't any explicit one. And stuff will work out ok for the most part as 0 gets accepted as the use-natural scaling. But we need a consistent approach to what a font's width means (or hide it away from anything outside of vcl and only give them a scaling factor that they can tweak) We could a) use the windows approach and always make it xAvgCharWidth, and add some code to suck it out of os2 header for the freetype code, and get the average manually for the X font stuff, and fixing up everything which thinks width == height means default width to not think that. Some windows-esque code stays happy here I guess ( e.g. grep for WIN32 in drawinglayer/source/primitive2d/) and the wmf exporter stays as it is. The other one I guess is to either always make the font width metric equal to the height as the flag as the "no scaling" basis, and add some "convert to WindowsLOGICALWidth" api which can get/calculate the tmAveCharWidth value and convert the scaling into terms relative to that. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- 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]
