These are good suggestions. I am fully aware of the shortcomings that
you pointed out, but the only other option seemed to be to codify the
mappings in IF, similar to your first suggestion. However that would
mean changing IF which is not something we are keen to do since that
impacts applications that rely on the current format.
Are you saying that with your second approach there is no need to change IF?
On 4/24/13 7:38 PM, Glenn Adams wrote:
Sure. One way to do this would be to add child elements to the <font/>
element in IF output as follows:
<font family="Lateef" style="normal" ...>
<pua code="0xE000" gid="139"/>
<pua code="0xE001" gid="481"/>
<pua code="0xE002" gid="219"/>
</font>
where these PUA mappings are collected by iterating over the
characters of TextAreas governed by the <font/> element. These
characters might be iterated upon invoking TextArea.add{Word,Space},
and collecting this info in text areas.
Alternatively, MultiByteFont.getUsedGlyphs() could be used to (1)
determine which glyph codes were referenced by the document, (2) given
these used codes, iterate of the the CMAP mappings to find which PUA
codes were generated for those glyph codes, then (3) output the <pua/>
elements (above) as required.
Finally, when reading an IF file, these <pua/> elements would be used
to augment the font's CMAP (keeping in mind that when reading the
font, MultiByteFont.createPrivateUseMappings() may have already been
called, and thus the mappings in <pua/> elements may need to be
replaced or merged.
I can imagine various other optimizations on the above theme to make
this readily workable.
On Wed, Apr 24, 2013 at 3:18 AM, Chris Bowditch
<[email protected] <mailto:[email protected]>> wrote:
Hi Glenn,
Can you suggest an alternative approach please?
Thanks,
Chris
On 24/04/2013 02:41, Glenn Adams wrote:
I don't like this. It negates any additional processing that
may have occurred, such as letter spacing. It requires the IF
to repeat part of the layout process. Bad idea.
On Tue, Apr 23, 2013 at 3:11 PM, Luis Bernardo
<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
With the approach implemented by Simon what gets written
to the IF
file is the original sequence, not the mapped sequence.
Then when
generating PDF from IF the same code that would generate the
synthesized mappings when generating PDF straight from FO is
called to recreate the mappings. So I don't think we can
say there
is information about the mappings in the text nodes.
On 4/23/13 5:50 AM, Glenn Adams wrote:
Ah, I reread your earlier (private) message. I see the
problem
has to do with the use of synthesized PUA mappings.
Here, the
problem really is that the font should always have a
CMAP entry
that maps to every glyph that can be produced by the GSUB
process. However, not all fonts do this, so in the
case in point,
we have to synthesize some mapping, from which we have
to turn to
PUA assignments. This works when we generate PDF since we
generate a subset font that contains the synthesized
mappings.
However, I can see that if this is going to IF instead
of PDF/PS,
then we need to find a way to recreate those
synthesized mappings.
I think this information is really font-specific, and
should not
be tied to specific text nodes though. So if Simon's
fix uses
text nodes, then that is probably not the best approach.
On Mon, Apr 22, 2013 at 10:45 PM, Glenn Adams
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
wrote:
I'm presently at W3C WG meetings this week, but
I'll try to
get on my schedule. I'm not sure what the
IF->PS/PDF problem
is, since the IF->PDF path is clearly working from
my tests.
On Mon, Apr 22, 2013 at 4:27 PM, Luis Bernardo
<[email protected]
<mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
Glenn,
Can you give your opinion about the approach
used by
Simon? As I mentioned before (in a private
message), the
IF -> PS/PDF route does not work in your
original CS
patch (for the languages that CS targets) due
to the
mapped sequences. Simon's approach works but
requires
keeping the original sequences alongside the
mapped ones.
I think it is a good approach but I would like
to know if
you have a better suggestion before we apply
the patch.
Thanks,
Luis
On 4/22/13 3:23 PM, Chris Bowditch (JIRA) wrote:
[
https://issues.apache.org/jira/browse/FOP-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch reassigned FOP-2210:
-----------------------------------
Assignee: Chris Bowditch
[PATCH] Complex script IF to output
missing glyphs
--------------------------------------------------
Key: FOP-2210
URL:
https://issues.apache.org/jira/browse/FOP-2210
Project: Fop
Issue Type: Bug
Reporter: simon steiner
Assignee: Chris Bowditch
Attachments: csspeedtrunk.patch,
fop.xconf, test.fo <http://test.fo>
<http://test.fo>
fop test.fo <http://test.fo>
<http://test.fo> -c fop.xconf -if
application/pdf expected.if.xml
fop -c fop.xconf -ifin expected.if.xml
out.pdf
--
This message is automatically generated by
JIRA.
If you think it was sent incorrectly,
please contact
your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
