Details

    • Bug
    • Status: Resolved
    • Resolution: Fixed
    • 1.8
    • None
    • GVT Text
    • Operating System: All
      Platform: All

    Description

      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".

      Attachments

        1. batik-font-matching.diff
          5 kB
          Jeremias Maerki

        Issue Links

          Activity

            Attachment batik-font-matching.diff has been added with description: Patch to improve font matching

            jeremias@apache.org Jeremias Maerki added a comment - Attachment batik-font-matching.diff has been added with description: Patch to improve font matching

            (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 BATIK-825 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 BATIK-872 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.)?

            helder.magalhaes@gmail.com Helder Magalhães added a comment - (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 BATIK-825 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 BATIK-872 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.)?
            deweese@apache.org Thomas DeWeese added a comment -

            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());

            deweese@apache.org Thomas DeWeese added a comment - 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());

            It definitely fixes BATIK-825 but I haven't looked closely at BATIK-872 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.

            jeremias@apache.org Jeremias Maerki added a comment - It definitely fixes BATIK-825 but I haven't looked closely at BATIK-872 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.

            (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

            helder.magalhaes@gmail.com Helder Magalhães added a comment - (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

            (In reply to comment #6)
            > *** BATIK-940 has been marked as a duplicate of this bug. ***

            BATIK-940 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).

            helder.magalhaes@gmail.com Helder Magalhães added a comment - (In reply to comment #6) > *** BATIK-940 has been marked as a duplicate of this bug. *** BATIK-940 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).

            May this issue address BATIK-612 as well?

            helder.magalhaes@gmail.com Helder Magalhães added a comment - May this issue address BATIK-612 as well?

            Patch applied with the modification indicated by Thomas:
            http://svn.apache.org/viewvc?rev=1084212&view=rev

            Helder wrote: "May this issue address BATIK-612 as well?"
            I don't know but it sounds like something different. My change is confined to the FontFamilyManager.

            jeremias@apache.org Jeremias Maerki added a comment - Patch applied with the modification indicated by Thomas: http://svn.apache.org/viewvc?rev=1084212&view=rev Helder wrote: "May this issue address BATIK-612 as well?" I don't know but it sounds like something different. My change is confined to the FontFamilyManager.

            People

              batik-dev@xmlgraphics.apache.org Batik Developer's Mailing list
              jeremias@apache.org Jeremias Maerki
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: