[
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
> ---
[
https://issues.apache.org/jira/browse/FOP-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Bowditch reassigned FOP-2210:
---
Assignee: (was: Chris Bowditch)
> [PATCH] Complex script IF to output missing glyphs
>
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
ori
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 wrote:
>
> Glenn,
>
> Can you give your opinion about the approach
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
c
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
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 wrote:
>
> With the approach implemented by Simon what gets written to the IF
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
Sure. One way to do this would be to add child elements to the
element in IF output as follows:
where these PUA mappings are collected by iterating over the characters of
TextAreas governed by the element. These characters might be
iterated upon invoking TextArea.add{Word,Space}, and
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 applica
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 mak
For our use cases, it would be much better to add new child elements to IF or
do other similar extensions, that having to repeat part of the costly layout
process. Besides repeating, the FO -> IF is easily executed by multiple
threads, while the IF->PDF can not be parallelised (without big chang
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.
Thanks,
Chris
On 24/04/2013 23
On 25/04/13 10:35, Alexios Giotis wrote:
> For our use cases, it would be much better to add new child elements to IF or
> do other similar extensions, that having to repeat part of the costly layout
> process. Besides repeating, the FO -> IF is easily executed by multiple
> threads, while the I
On Thu, Apr 25, 2013 at 2:31 AM, Vincent Hennebert wrote:
>
> It doesn’t shock me to store text as text in the IF and to re-do the
> glyph mapping when rendering it to the final output format. This is
> actually how it is done ATM.
>
I think this a bad idea for the reasons that Alexios mentioned,
On 25/04/13 17:48, Glenn Adams wrote:
> On Thu, Apr 25, 2013 at 2:31 AM, Vincent Hennebert
> wrote:
>
>>
>> It doesn’t shock me to store text as text in the IF and to re-do the
>> glyph mapping when rendering it to the final output format. This is
>> actually how it is done ATM.
>>
>
> I think t
On Thu, Apr 25, 2013 at 1:08 PM, Vincent Hennebert wrote:
> On 25/04/13 17:48, Glenn Adams wrote:
> > On Thu, Apr 25, 2013 at 2:31 AM, Vincent Hennebert >wrote:
> >
> >>
> >> It doesn’t shock me to store text as text in the IF and to re-do the
> >> glyph mapping when rendering it to the final out
On 25/04/13 22:33, Glenn Adams wrote:
> On Thu, Apr 25, 2013 at 1:08 PM, Vincent Hennebert
> wrote:
>
>> On 25/04/13 17:48, Glenn Adams wrote:
>>> On Thu, Apr 25, 2013 at 2:31 AM, Vincent Hennebert >> wrote:
>>>
It doesn’t shock me to store text as text in the IF and to re-do the
g
On Fri, Apr 26, 2013 at 12:59 PM, Vincent Hennebert wrote:
> On 25/04/13 22:33, Glenn Adams wrote:
> > On Thu, Apr 25, 2013 at 1:08 PM, Vincent Hennebert >wrote:
> >
> >> On 25/04/13 17:48, Glenn Adams wrote:
> >>> On Thu, Apr 25, 2013 at 2:31 AM, Vincent Hennebert <
> vhenneb...@gmail.com
> >>>
On 26 Apr 2013, at 23:45, Glenn Adams wrote:
> (3) I am not (yet) convinced in the wisdom of supporting modification to the
> IF text, but I'm open to learn about use cases;
>
Hi Glenn,
Interesting thread, I will just attempt to describe some use cases where I need
to modify the IF text.
Hi Glenn, Alexios,
One of the key requirements when we implemented IF XML, was the ability
to make modifications. Thanks to Alex for provide a list of business
reasons why that is necessary. I agree with those use cases. Some of the
others are adding barcodes, OMR marks, large file page number
On Sun, Apr 28, 2013 at 12:15 PM, Alexios Giotis wrote:
> On 26 Apr 2013, at 23:45, Glenn Adams wrote:
>
> > (3) I am not (yet) convinced in the wisdom of supporting modification to
> the IF text, but I'm open to learn about use cases;
> >
>
>
>
> Hi Glenn,
>
> Interesting thread, I will just att
On Mon, Apr 29, 2013 at 6:16 AM, Chris Bowditch
wrote:
> Hi Glenn, Alexios,
>
> One of the key requirements when we implemented IF XML, was the ability to
> make modifications. Thanks to Alex for provide a list of business reasons
> why that is necessary. I agree with those use cases. Some of the
23 matches
Mail list logo
