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 <bowditch_ch...@hotmail.com <mailto:bowditch_ch...@hotmail.com>> 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
        <lmpmberna...@gmail.com <mailto:lmpmberna...@gmail.com>
        <mailto:lmpmberna...@gmail.com
        <mailto:lmpmberna...@gmail.com>>> 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
            <gl...@skynav.com <mailto:gl...@skynav.com>
                <mailto:gl...@skynav.com <mailto:gl...@skynav.com>>>
            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
                    <lmpmberna...@gmail.com
            <mailto:lmpmberna...@gmail.com>
            <mailto:lmpmberna...@gmail.com
            <mailto:lmpmberna...@gmail.com>>> 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









Reply via email to