[ 
https://issues.apache.org/jira/browse/FOP-2539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15009834#comment-15009834
 ] 

Andreas L. Delmelle edited comment on FOP-2539 at 11/17/15 11:33 PM:
---------------------------------------------------------------------

Having a go at adding support for the Macintosh/Roman table -- which is fairly 
straightforward, since it is a simple 1-1 mapping -- I noticed that the 
situation there is very similar to the Windows/Symbol one, only there the 
codepoints for regular latin alphabet are _directly_ mapped to the symbol 
glyphs, i.e. without going via the 'private use area'. So, regular latin 
characters are also not supported in the Apple OTF implementation of the Symbol 
font. There are no glyphs "A", "b", etc. in that font.

Since the code currently processes the Windows/Symbol mapping _only_ if there 
is no Windows/Unicode mapping available, that bit of code really does not do 
anything if the TTF contains both. Even if we were to process both mappings, 
then the one that happens to be processed first will take precedence, i.e. the 
code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 
to glyph 'α', but not both, as is the case in both Windows and OS X when you 
type text in a text editor or word processor.

To get back on topic for this particular issue: I still very much suspect this 
to be an encoding issue in the source file, maybe as the result of either 
copy-pasting text or reading from a stream with the default platform encoding. 
Notice that the user mentions both Windows and Unix as affected; if the default 
encoding on both platforms does not match, this is typically the result -- rule 
of thumb: *always* specify an explicit encoding when setting up 
Input/OutputStreamReaders. One could argue that Java makes it far too easy for 
novices to make mistakes here, leading to issues that can be a real pain to 
trace to their origin... ;)


was (Author: adelmelle):
Having a go at adding support for the Macintosh/Roman table --which is fairly 
straightforward, since it is a simple 1-1 mapping-- I noticed that the 
situation there is very similar to the Windows/Symbol one, only there the 
codepoints for regular latin alphabet are _directly_ mapped to the symbol 
glyphs, i.e. without going via the 'private use area'. So, regular latin 
characters are also not supported in the Apple OTF implementation of the Symbol 
font. There are no glyphs "A", "b", etc. in that font.

Since the code currently processes the Windows/Symbol mapping _only_ if there 
is no Windows/Unicode mapping available, that bit of code really does not do 
anything if the TTF contains both. Even if we were to process both mappings, 
then the one that happens to be processed first will take precedence, i.e. the 
code currently allows mapping _either_ codepoint U+03B1 _or_ codepoint U+0061 
to glyph 'α', but not both, as is the case in both Windows and OS X when you 
type text in a text editor or word processor.

To get back on topic for this particular issue: I still very much suspect this 
to be an encoding issue in the source file, maybe as the result of either 
copy-pasting text or reading from a stream with the default platform encoding. 
Notice that the user mentions both Windows and Unix as affected; if the default 
encoding on both platforms does not match, this is typically the result -- rule 
of thumb: *always* specify an explicit encoding when setting up 
Input/OutputStreamReaders. One could argue that Java makes it far too easy for 
novices to make mistakes here, leading to issues that can be a real pain to 
trace to their origin... ;)

> Apache PDF issue with Symbol.ttf
> --------------------------------
>
>                 Key: FOP-2539
>                 URL: https://issues.apache.org/jira/browse/FOP-2539
>             Project: FOP
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: Windox, unix
>            Reporter: Sushmitha
>         Attachments: symbol_test.fo, symbol_test_2.fo
>
>
> I have Symbol.ttf, configured the same in config file. Symbol font is not 
> applying properly.
> Please find the below details
> FOP version - 1.0
> OS - Unix, Windows
> XSL-FO desc:
> <fo:block font-family="Symbol">
> Abcdefgh α β γ
> </fo:block>
> Result - the charcters are not displaying properly and they are not human 
> readable format
> fop.xconf:-
> <renderers>
> <renderer mime="application/pdf">
> <fonts>
> <font metrics-url="Symbol.xml" embed-url="Symbol.ttf">
> <font-triplet name="Symbol" style="normal" weight="normal"/>
> </font>
> </fonts>
> </renderer>
> <renderers>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to