Bug 49968 - [PATCH] Improve font matching
Summary: [PATCH] Improve font matching
Status: RESOLVED FIXED
Alias: None
Product: Batik - Now in Jira
Classification: Unclassified
Component: GVT Text (show other bugs)
Version: 1.8
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Batik Developer's Mailing list
URL:
Keywords: PatchAvailable
: 44828 48856 52747 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-21 14:14 UTC by Jeremias Maerki
Modified: 2012-02-23 13:51 UTC (History)
3 users (show)



Attachments
Patch to improve font matching (5.23 KB, application/octet-stream)
2010-09-21 14:14 UTC, Jeremias Maerki
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremias Maerki 2010-09-21 14:14:05 UTC
Created attachment 26061 [details]
Patch to improve font matching

The attached patch does three things:

1. Internally register not only the font families but also the actual font names (FontFamilyResolver).

Example: Where "Univers" is a font family, the font name "Univers 45 Light" is not currently registered. So if this is used, no match is found and the fallback "SansSerif" is used.

2. Handle all CSS font weights for Java VMs >= 1.5 (TextUtilities).

There was a simplification in place for handling cases in JVMs prior to 1.5.

3. Handle the case where a font family with spaces contains an integer value (ex. "Univers 45 Light"), but is not in quotes (FontFamilyManager).

Until now, only the case style="font-family: Univers Bold" would be handled but not style="font-family: Univers 45 Light".
Comment 1 Helder Magalhães 2010-09-22 05:17:50 UTC
(In reply to comment #0)
> Created an attachment (id=26061) [details]
> Patch to improve font matching

Cool stuff. Thanks, Jeremias! ;-)


> 3. Handle the case where a font family with spaces contains an integer value
> (ex. "Univers 45 Light"), but is not in quotes (FontFamilyManager).

Does this mean that bug 44828 gets fixed by this as well? :-)


(from the patch)
+        //Also register all font names, not just font families.
+        //Example: Font Family: "Univers", but Font Name: "Univers 45 Light"
+        //Without this, matching "Univers 45 Light" is not possible.
+        Font[] allFonts = env.getAllFonts();
+        for (int i = 0; i < allFonts.length; i++) {
+            Font f = allFonts[i];
+            fonts.put(f.getFontName().toLowerCase(), f.getFontName());
+        }

Does this mean that bug 46374 gets fixed by this as well? :-)


Generally, the patch looks good to me. Thomas, could you also take a look and state whether this is ready to land or if anything else is needed (tests for regard, etc.)?
Comment 2 Thomas Deweese 2010-09-22 05:43:44 UTC
Mostly I think it's fine, just for my understanding under strict CSS rules are you allowed to have font families with numbers w/o quotes or underbars or collapsed spaces?

Also it looks to me like this is left over from dev/debug:
@@ -170,6 +176,7 @@

             if (lu == null) {
                 return result;
             }
+            short v1 = lu.getLexicalUnitType();
             if (lu.getLexicalUnitType() != LexicalUnit.SAC_OPERATOR_COMMA) {
                 throw createInvalidLexicalUnitDOMException
                     (lu.getLexicalUnitType());
Comment 3 Jeremias Maerki 2010-09-22 07:59:07 UTC
It definitely fixes bug 44828, but I haven't looked closely at bug 46374, yet. I have to dash of to Germany now and will be online again mid next week. I'll take another look then.

Thanks, Thomas, for catching that little mistake. Eclipse was telling me about it, but I've missed it nonetheless.
Comment 4 Helder Magalhães 2010-09-29 01:18:23 UTC
(In reply to comment #2)
> Mostly I think it's fine, just for my understanding under strict CSS rules are
> you allowed to have font families with numbers w/o quotes or underbars or
> collapsed spaces?

Apparently the specifications are quite unclear regarding that [1] [2]. Nevertheless, there are couple links [3] [4] that hint towards that (allowing numbers in font families) be formally specified in a near future. According to what I was able to investigate, the underspecified behavior in the current specs. make it even possible to use virtually any character (assuming proper escaping, whenever needed). :-)

[1] http://www.w3.org/TR/CSS2/fonts.html#value-def-family-name
[2] http://www.w3.org/TR/css3-values/#font-families
[3] http://lists.w3.org/Archives/Public/www-style/2010Mar/0386.html
[4] http://wiki.csswg.org/spec/css2.1#issue-114
Comment 5 Helder Magalhães 2010-09-29 05:14:27 UTC
*** Bug 44828 has been marked as a duplicate of this bug. ***
Comment 6 Helder Magalhães 2010-10-04 11:52:29 UTC
*** Bug 48856 has been marked as a duplicate of this bug. ***
Comment 7 Helder Magalhães 2010-10-04 11:54:20 UTC
(In reply to comment #6)
> *** Bug 48856 has been marked as a duplicate of this bug. ***

Bug 48856 comment 2 might be worth to take a look at, although I suspect (without actually checking) that's what's being done already (within the patch). :-)
Comment 8 Helder Magalhães 2010-10-06 05:23:12 UTC
May this issue address bug 38207 as well?
Comment 9 Jeremias Maerki 2011-03-22 11:25:27 UTC
Patch applied with the modification indicated by Thomas:
http://svn.apache.org/viewvc?rev=1084212&view=rev

Helder wrote: "May this issue address bug 38207 as well?"
I don't know but it sounds like something different. My change is confined to the FontFamilyManager.
Comment 10 Jeremias Maerki 2012-02-23 13:51:07 UTC
*** Bug 52747 has been marked as a duplicate of this bug. ***