Fop
  1. Fop
  2. FOP-2029

[PATCH] SVG font being painted as shapes when font present in the system

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: fonts
    • Labels:
      None
    • Environment:
      Operating System: Linux
      Platform: PC
    • External issue ID:
      52849

      Description

      When a SVG embeds a font the text in the generated PDF/PS is being stroked as shapes even in situations where the font is present in the system and known to FOP. The attached *.fo can be used to show the issue. Looking at the generated PDF (with no flate) or PS one sees that there is no text even though one of the fonts is known to FOP.

      1. svg-fonts.fo
        3 kB
        Luis Bernardo
      2. apachefop.patch
        10 kB
        Luis Bernardo
      3. apachefop2.patch
        13 kB
        Luis Bernardo

        Activity

        Hide
        Mehdi Houshmand added a comment -

        Oops, forgot to say, thanks for the good work!

        Show
        Mehdi Houshmand added a comment - Oops, forgot to say, thanks for the good work!
        Hide
        Mehdi Houshmand added a comment -

        This has been commited in r1301445. I made a few changes fixing checkstyle issues concerning javadocs and line lengths. I also made the Set in the LoggingEventListener "final", there doesn't seem much point in lazy loading this member.

        Show
        Mehdi Houshmand added a comment - This has been commited in r1301445. I made a few changes fixing checkstyle issues concerning javadocs and line lengths. I also made the Set in the LoggingEventListener "final", there doesn't seem much point in lazy loading this member.
        Hide
        Luis Bernardo added a comment -

        Attachment apachefop2.patch has been added with description: updated patch

        Show
        Luis Bernardo added a comment - Attachment apachefop2.patch has been added with description: updated patch
        Hide
        Luis Bernardo added a comment -

        I put some more thought into this and I think it is OK to remove the log.warn() from FontInfo (from the notify* methods) and just rely on the event listener. The decision whether to output the log messages was then moved to the LogginEventListener.

        Show
        Luis Bernardo added a comment - I put some more thought into this and I think it is OK to remove the log.warn() from FontInfo (from the notify* methods) and just rely on the event listener. The decision whether to output the log messages was then moved to the LogginEventListener.
        Hide
        Luis Bernardo added a comment -

        I confess I did not put a lot of thought into that and instead used the same pattern that was already present in the that class in the notifyFontReplacement() method. But the remark is a good one. In a more general event framework the listener could even indicate at the time of registration of interest in a particular class of events whether to receive repeated events or just unique events. In the current event framework, yes, I think that letting the listener decide whether to notify or not the user makes sense. However, the problem I see is with the logging. If there is no listener the code falls back to log.warn() calls and I think we do not want repeated messages to clutter the logs. Maybe that is the reason it was done like this originally?

        Show
        Luis Bernardo added a comment - I confess I did not put a lot of thought into that and instead used the same pattern that was already present in the that class in the notifyFontReplacement() method. But the remark is a good one. In a more general event framework the listener could even indicate at the time of registration of interest in a particular class of events whether to receive repeated events or just unique events. In the current event framework, yes, I think that letting the listener decide whether to notify or not the user makes sense. However, the problem I see is with the logging. If there is no listener the code falls back to log.warn() calls and I think we do not want repeated messages to clutter the logs. Maybe that is the reason it was done like this originally?
        Hide
        Mehdi Houshmand added a comment -

        Hi Luis,

        Just thinking about this, I think maybe the FontInfo class shouldn't really be responsible for remembering that which notifications it has sent. It just just notify the FontEventListener, then the FontEventListener should decide whether to notify the user or not.

        Just a thought, maybe I'm missing something... I see that there's a loggedFontKeys that does something similar, maybe there's a reason for that? If anyone else has thoughts, please do chime in.

        Mehdi

        Show
        Mehdi Houshmand added a comment - Hi Luis, Just thinking about this, I think maybe the FontInfo class shouldn't really be responsible for remembering that which notifications it has sent. It just just notify the FontEventListener, then the FontEventListener should decide whether to notify the user or not. Just a thought, maybe I'm missing something... I see that there's a loggedFontKeys that does something similar, maybe there's a reason for that? If anyone else has thoughts, please do chime in. Mehdi
        Hide
        Luis Bernardo added a comment -

        title updated.

        Show
        Luis Bernardo added a comment - title updated.
        Hide
        Luis Bernardo added a comment -

        Attachment apachefop.patch has been added with description: patch

        Show
        Luis Bernardo added a comment - Attachment apachefop.patch has been added with description: patch
        Hide
        Luis Bernardo added a comment -

        the attached patch addresses the issue: fonts known to FOP as stroked as text even if embedded in SVG.

        Show
        Luis Bernardo added a comment - the attached patch addresses the issue: fonts known to FOP as stroked as text even if embedded in SVG.
        Hide
        Luis Bernardo added a comment -

        Attachment svg-fonts.fo has been added with description: test *.fo file

        Show
        Luis Bernardo added a comment - Attachment svg-fonts.fo has been added with description: test *.fo file

          People

          • Assignee:
            fop-dev
            Reporter:
            Luis Bernardo
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development