Hi Glenn, Luis,

It's true that modifying IF can cause us problems for older programs designed to modify it. However, since none of those older applications work with CS, then I'm confident that the additional elements proposed by Glenn shouldn't be a problem.



On 24/04/2013 23:52, Glenn Adams wrote:
I see no option but to modify IF. We modified IF for 1.1 in the first place. We have recently made quite a number of backward incompatible changes to the FOP public APIs. I expect the next release will need to bump the major version to 2 for FOP due to these changes, so there is little risk in making a change in IF. If there are other, useful changes to IF that have been postponed, then perhaps they should be reconsidered now as well.

On Wed, Apr 24, 2013 at 3:26 PM, Luis Bernardo <lmpmberna...@gmail.com <mailto:lmpmberna...@gmail.com>> wrote:

    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"/>

    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>>

        Hi Glenn,

        Can you suggest an alternative approach please?



        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

            On Tue, Apr 23, 2013 at 3:11 PM, Luis Bernardo
            <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

                    On Mon, Apr 22, 2013 at 10:45 PM, Glenn Adams
                <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
                <mailto:lmpmberna...@gmail.com>>> wrote:


                            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.


                            On 4/22/13 3:23 PM, Chris Bowditch (JIRA)


                                Chris Bowditch reassigned FOP-2210:

                                     Assignee: Chris Bowditch

                                    [PATCH] Complex script IF to
                output missing glyphs

                 Key: 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:

Reply via email to