Bug 52849 - [PATCH] SVG font being painted as shapes when font present in the system
Summary: [PATCH] SVG font being painted as shapes when font present in the system
Status: CLOSED FIXED
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: fonts (show other bugs)
Version: all
Hardware: PC Linux
: P2 minor
Target Milestone: ---
Assignee: fop-dev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-07 14:51 UTC by Luis Bernardo
Modified: 2012-03-28 08:50 UTC (History)
0 users



Attachments
test *.fo file (2.88 KB, text/x-xslfo)
2012-03-07 14:51 UTC, Luis Bernardo
Details
patch (10.35 KB, patch)
2012-03-07 14:55 UTC, Luis Bernardo
Details | Diff
updated patch (13.15 KB, patch)
2012-03-14 16:16 UTC, Luis Bernardo
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luis Bernardo 2012-03-07 14:51:37 UTC
Created attachment 28431 [details]
test *.fo file

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.
Comment 1 Luis Bernardo 2012-03-07 14:55:40 UTC
Created attachment 28432 [details]
patch

the attached patch addresses the issue: fonts known to FOP as stroked as text even if embedded in SVG.
Comment 2 Luis Bernardo 2012-03-07 14:56:11 UTC
title updated.
Comment 3 Mehdi Houshmand 2012-03-07 15:07:51 UTC
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
Comment 4 Luis Bernardo 2012-03-07 23:14:22 UTC
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?
Comment 5 Luis Bernardo 2012-03-14 16:16:29 UTC
Created attachment 28466 [details]
updated patch

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.
Comment 6 Mehdi Houshmand 2012-03-16 11:45:45 UTC
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.
Comment 7 Mehdi Houshmand 2012-03-16 11:46:40 UTC
Oops, forgot to say, thanks for the good work!