[
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:41 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/Writers. 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)
