Using swing or awt one can use something called "FontMetrics". FontMetrics lets you pass in a String and the font info and you get out the lenght in various units. Currently, user's and POI people alike have to "guess" or create "magic formulas" that just happen to be right in order to get the cell sizing, etc. correct. We cannot just use the swing or awt fontmetrics because 1> thats gui stuff 2> swing is a yucky libarary we don't want to depend on and 3> it creates a dependancy on X. Whoever creates a clean room (and differently named) FontMetrics will be revealed as a really cool joe (or jo)!
For the record, jdk1.4 allows headless operations, so this is moot. However its obviously still relevant for jdk1.3 and below. If we need such functionality in POI, maybe a conditional compilation/execution may be tried in the interim before such an implementation is available?
It will probably still be an issue even with 1.4. What if the server you're running on doesn't have the font you require? A fair bet if the server's not windows.
Look at the FOP project; they have font managing utilities we could use. JDK headless is not a 100% solution, and FontMetrics sucks on most implementation, and is generally not consistent between versions and platforms.
agreed (all around)
Agreed. and corrected.
This might just be a job for super-glen or Ken (the XML boyz). The FOP stuff is in XML, in theory we could generate our implementation from their XML...hehe..
Also, the PDFBox project that's currently incubating has pretty good font metrics in place. The code should hit Apache svn pretty soon, and I'll take a look at whether it could be reused in POI.
See http://svn.apache.org/repos/asf/pdfbox/trunk/pdfbox/src/main/appended-resources/META-INF/LICENSE Apache PDFBox should have code that we can use to provide Font Metrics. Unfortunately, this is only for the Base 14 fonts. The usefulness of having non-Java font handling is to be able to measure text for a document where you do not have the real font. If you have the real font on your system then you can run in headless mode and use standard routines. If you do not have the correct font, if you can detect whether you are using a fixed, serif or non-serif then one of the base 14 can be a reasonable though not accurate stand in for the font. Something to discuss at Apachecon 2010
Description of the changes made in the patch: XSSFImportFromXML will now consider the data type defined in the XML schema when filling the data of the xml into cells. It differentiates between Boolean, Integer, Data and String. Any unknown data types are handled as Strings. If the string value can't be parsed into the required data type (e.g. Integer or Date) it will result in a IllegalArgumentException. Currently not all STXmlDataTypes are handled. For an example refer to the test and test data in the patch.
(In reply to Sandra from comment #9) > Description of the changes made in the patch: > > XSSFImportFromXML will now consider the data type defined in the XML schema > when filling the data of the xml into cells. It differentiates between > Boolean, Integer, Data and String. Any unknown data types are handled as > Strings. If the string value can't be parsed into the required data type > (e.g. Integer or Date) it will result in a IllegalArgumentException. > Currently not all STXmlDataTypes are handled. > For an example refer to the test and test data in the patch. Sorry wrong bug. Please ignore
I don't think anybody was actively looking at this for years, therefore closing this for now, please reopen if you plan to work on something like this.