Bug 6842 - A clean-room implementation is needed of "FontMetrics"
Summary: A clean-room implementation is needed of "FontMetrics"
Status: RESOLVED WONTFIX
Alias: None
Product: POI
Classification: Unclassified
Component: POI Overall (show other bugs)
Version: 3.11-dev
Hardware: Other other
: P3 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: POI Developers List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-03-04 13:05 UTC by Andy Oliver
Modified: 2016-04-10 20:57 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Oliver 2002-03-04 13:05:11 UTC
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)!
Comment 1 Avik Sengupta 2002-06-20 10:07:57 UTC
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?
Comment 2 Glen Stampoultzis 2002-06-20 11:53:07 UTC
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.
Comment 3 Nicola Ken Barozzi 2002-06-20 12:16:23 UTC
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.
Comment 4 Andy Oliver 2002-06-20 13:32:50 UTC
agreed (all around)
Comment 5 Avik Sengupta 2002-06-20 13:44:35 UTC
Agreed. and corrected. 
Comment 6 Andy Oliver 2002-06-20 14:00:28 UTC
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..
Comment 7 Jukka Zitting 2008-06-16 14:05:22 UTC
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.
Comment 8 David Fisher 2010-10-29 17:44:26 UTC
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
Comment 9 Sandra 2015-05-05 10:28:05 UTC
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.
Comment 10 Sandra 2015-05-05 10:29:58 UTC
(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
Comment 11 Dominik Stadler 2016-04-10 20:57:34 UTC
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.