[jira] [Commented] (FOP-2247) Vertical table border differs width, when horizontal border is omitted

[Guest User (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13687599#comment-13687599
 ] 

Guest User commented on FOP-2247:
-

I've read the mentioned thread from November 2012 and I see that this is a 
complex problem and there is no need to discuss this again. One of the hints to 
deal with it, is to use nested tables. However, in most cases nested tables 
won't help. One of the major reasons is, that tables do not support 
height="100%". Will this be possible in coming up versions?

> Vertical table border differs width, when horizontal border is omitted
> --
>
> Key: FOP-2247
> URL: https://issues.apache.org/jira/browse/FOP-2247
> Project: Fop
>  Issue Type: Bug
>  Components: pdf
>Affects Versions: 1.1
> Environment: Windows 7, JRE1.6
>Reporter: Guest User
>Priority: Minor
>
> Following description applies to PDF view.
> When using a table grid to place contents on a page, the border width of the 
> cell borders differ in their width. This happens when both, top and bottom 
> border, are omitted. Here is an example, which nicely demonstrates the 
> effect. See the comment in the code to know, which borders will be painted 
> wrong:
> 
> http://www.w3.org/1999/XSL/Format";>
>   
>  page-width="210mm" page-height="297mm" margin="1cm">
>   
> 
>   
>   
> 
> 
>   
>   
>border-bottom="none"> 
> 
>border-bottom="none"> 
> 
>border-bottom="none"> 
> 
>   
>   
>border-top="none" border-bottom="none"> white-space-treatment="preserve"> 
>   
>border-top="none" border-bottom="none"> white-space-treatment="preserve"> 
>border-top="none" border-bottom="none"> white-space-treatment="preserve"> 
>   
>   
>border-top="none"> 
> 
>border-top="none"> 
> 
>border-top="none"> 
> 
>   
>   
>   
>   
>   
> 
>   
> 
>   
> 
>   
>   
>   
> 
>   
> 
> This can be seen on screen and on paper, as well.

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

Re: FOP using ICU?

[Glenn Adams]

On Wed, Jun 19, 2013 at 1:05 AM, Chris Bowditch
wrote:

> Hi Glenn,
>
>
> On 18/06/2013 11:12, Glenn Adams wrote:
>
>> To be more clear, I propose we replace FOP's implementation of UAX14 with
>> use of ICU's line break iterator, and that ICU becomes a standard
>> dependency for FOP.
>>
>> However, before taking a decision on this, allow me to create a branch
>> (on github) that actually makes this change so that folks can evaluate it.
>> Is that a reasonable approach?
>>
>
> +1, but I think we should create the branch in SVN as Vincent mentioned.
> SVN is still the Version Control system used by the XML Graphics project.
>

When I've completed the work in a github branch of a fork of the apache/fop
mirror, I'll upload it to an SVN branch for folks to review who prefer SVN.
Me, I've stopped using SVN for active development. Github is just so much
better.

[jira] [Resolved] (FOP-2246) SEVERE: Exception java.lang.IllegalArgumentException: min (1650) > opt (0)

[Luis Bernardo (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luis Bernardo resolved FOP-2246.


   Resolution: Fixed
Fix Version/s: trunk

fixed in http://svn.apache.org/viewvc?view=revision&revision=1494364.

> SEVERE: Exception java.lang.IllegalArgumentException: min (1650) > opt (0)
> --
>
> Key: FOP-2246
> URL: https://issues.apache.org/jira/browse/FOP-2246
> Project: Fop
>  Issue Type: Bug
>  Components: pdf
>Affects Versions: 1.1
>Reporter: Yevgeniy Vostokov
> Fix For: trunk
>
> Attachments: ExpereResponse.fo, expereresponse.pdf, fop-log.txt, 
> xep-log.txt
>
>
> I am getting an Exception java.lang.IllegalArgumentException: min (1650) > 
> opt (0) 
> and PDF is not getting created.
> I can generate PDF from the same FO file using XEP. 
> If I remove the attribute word-spacing.minimum from the fo file it fixes it. 
> Apparently the code expects the optimum and maximum to be also specified if 
> the minimum is and in this case they are not. If I add optimum and maximim 
> attributes it works too.

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

Re: FOP using ICU?

[Chris Bowditch]

Hi Glenn,

On 18/06/2013 11:12, Glenn Adams wrote:
To be more clear, I propose we replace FOP's implementation of UAX14 
with use of ICU's line break iterator, and that ICU becomes a standard 
dependency for FOP.


However, before taking a decision on this, allow me to create a branch 
(on github) that actually makes this change so that folks can evaluate 
it. Is that a reasonable approach?


+1, but I think we should create the branch in SVN as Vincent mentioned. 
SVN is still the Version Control system used by the XML Graphics project.


Thanks,

Chris




On Tue, Jun 18, 2013 at 6:04 PM, Glenn Adams > wrote:


My position is that it is costing us in interoperability (I mean
lack thereof) by failing to use ICU. I don't see any issue about size.


On Tue, Jun 18, 2013 at 6:00 PM, Vincent Hennebert
mailto:vhenneb...@gmail.com>> wrote:

On 18/06/13 06:46, Glenn Adams wrote:
> Is there a reason FOP doesn't use ICU for determining line break
> boundaries? The FOP implementation of UAX14
(org.apache.fop.text.linebreak)
> seems to be out of date and basically unmaintained.
According to [1], a
> number of Apache projects are using it, including PDFBox,
Xalan, and Xerces.

I think the main reason in the past has been the size of the
ICU4J jar
compared to FOP’s own jar:
http://markmail.org/thread/krkqlircefpuxlse

I guess the topic could be revisited today. We could consider
adding it
as an optional dependency, or acknowledge that full Unicode
support is
taken for granted nowadays and use it by default.

>
> [1] http://site.icu-project.org/#TOC-Apache-Projects
>

Vincent

[jira] [Updated] (FOP-2265) [PATCH] Enable xlint cast

[simon steiner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

simon steiner updated FOP-2265:
---

Attachment: xlint.patch

> [PATCH] Enable xlint cast
> -
>
> Key: FOP-2265
> URL: https://issues.apache.org/jira/browse/FOP-2265
> Project: Fop
>  Issue Type: Bug
>Reporter: simon steiner
> Attachments: xlint.patch
>
>
> Avoid unnecessary casts

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

[jira] [Created] (FOP-2265) [PATCH] Enable xlint cast

[simon steiner (JIRA)]

simon steiner created FOP-2265:
--

 Summary: [PATCH] Enable xlint cast
 Key: FOP-2265
 URL: https://issues.apache.org/jira/browse/FOP-2265
 Project: Fop
  Issue Type: Bug
Reporter: simon steiner


Avoid unnecessary casts

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

Re: FOP using ICU?

[Glenn Adams]

By interoperability, I mean interoperability with different language line
breaking requirements. For example, Thai (and a number of other languages)
requires dictionary based support for line breaking. ICU supports this
today, while it is highly unlikely we would ever add this support to the
existing FOP implementation of UAX14.


On Tue, Jun 18, 2013 at 6:04 PM, Glenn Adams  wrote:

> My position is that it is costing us in interoperability (I mean lack
> thereof) by failing to use ICU. I don't see any issue about size.
>
>
> On Tue, Jun 18, 2013 at 6:00 PM, Vincent Hennebert 
> wrote:
>
>> On 18/06/13 06:46, Glenn Adams wrote:
>> > Is there a reason FOP doesn't use ICU for determining line break
>> > boundaries? The FOP implementation of UAX14
>> (org.apache.fop.text.linebreak)
>> > seems to be out of date and basically unmaintained. According to [1], a
>> > number of Apache projects are using it, including PDFBox, Xalan, and
>> Xerces.
>>
>> I think the main reason in the past has been the size of the ICU4J jar
>> compared to FOP’s own jar:
>> http://markmail.org/thread/krkqlircefpuxlse
>>
>> I guess the topic could be revisited today. We could consider adding it
>> as an optional dependency, or acknowledge that full Unicode support is
>> taken for granted nowadays and use it by default.
>>
>> >
>> > [1] http://site.icu-project.org/#TOC-Apache-Projects
>> >
>>
>> Vincent
>>
>
>

Re: FOP using ICU?

[Vincent Hennebert]

On 18/06/13 12:12, Glenn Adams wrote:
> To be more clear, I propose we replace FOP's implementation of UAX14 with
> use of ICU's line break iterator, and that ICU becomes a standard
> dependency for FOP.
> 
> However, before taking a decision on this, allow me to create a branch (on
> github) that actually makes this change so that folks can evaluate it. Is
> that a reasonable approach?

Sure, although creating a branch on Subversion would probably be
preferable.


> 
> On Tue, Jun 18, 2013 at 6:04 PM, Glenn Adams  wrote:
> 
>> My position is that it is costing us in interoperability (I mean lack
>> thereof) by failing to use ICU. I don't see any issue about size.
>>
>>
>> On Tue, Jun 18, 2013 at 6:00 PM, Vincent Hennebert 
>> wrote:
>>
>>> On 18/06/13 06:46, Glenn Adams wrote:
 Is there a reason FOP doesn't use ICU for determining line break
 boundaries? The FOP implementation of UAX14
>>> (org.apache.fop.text.linebreak)
 seems to be out of date and basically unmaintained. According to [1], a
 number of Apache projects are using it, including PDFBox, Xalan, and
>>> Xerces.
>>>
>>> I think the main reason in the past has been the size of the ICU4J jar
>>> compared to FOP’s own jar:
>>> http://markmail.org/thread/krkqlircefpuxlse
>>>
>>> I guess the topic could be revisited today. We could consider adding it
>>> as an optional dependency, or acknowledge that full Unicode support is
>>> taken for granted nowadays and use it by default.
>>>

 [1] http://site.icu-project.org/#TOC-Apache-Projects

>>>

Vincent

Re: FOP using ICU?

[Glenn Adams]

To be more clear, I propose we replace FOP's implementation of UAX14 with
use of ICU's line break iterator, and that ICU becomes a standard
dependency for FOP.

However, before taking a decision on this, allow me to create a branch (on
github) that actually makes this change so that folks can evaluate it. Is
that a reasonable approach?


On Tue, Jun 18, 2013 at 6:04 PM, Glenn Adams  wrote:

> My position is that it is costing us in interoperability (I mean lack
> thereof) by failing to use ICU. I don't see any issue about size.
>
>
> On Tue, Jun 18, 2013 at 6:00 PM, Vincent Hennebert 
> wrote:
>
>> On 18/06/13 06:46, Glenn Adams wrote:
>> > Is there a reason FOP doesn't use ICU for determining line break
>> > boundaries? The FOP implementation of UAX14
>> (org.apache.fop.text.linebreak)
>> > seems to be out of date and basically unmaintained. According to [1], a
>> > number of Apache projects are using it, including PDFBox, Xalan, and
>> Xerces.
>>
>> I think the main reason in the past has been the size of the ICU4J jar
>> compared to FOP’s own jar:
>> http://markmail.org/thread/krkqlircefpuxlse
>>
>> I guess the topic could be revisited today. We could consider adding it
>> as an optional dependency, or acknowledge that full Unicode support is
>> taken for granted nowadays and use it by default.
>>
>> >
>> > [1] http://site.icu-project.org/#TOC-Apache-Projects
>> >
>>
>> Vincent
>>
>
>

Re: FOP using ICU?

[Glenn Adams]

My position is that it is costing us in interoperability (I mean lack
thereof) by failing to use ICU. I don't see any issue about size.


On Tue, Jun 18, 2013 at 6:00 PM, Vincent Hennebert wrote:

> On 18/06/13 06:46, Glenn Adams wrote:
> > Is there a reason FOP doesn't use ICU for determining line break
> > boundaries? The FOP implementation of UAX14
> (org.apache.fop.text.linebreak)
> > seems to be out of date and basically unmaintained. According to [1], a
> > number of Apache projects are using it, including PDFBox, Xalan, and
> Xerces.
>
> I think the main reason in the past has been the size of the ICU4J jar
> compared to FOP’s own jar:
> http://markmail.org/thread/krkqlircefpuxlse
>
> I guess the topic could be revisited today. We could consider adding it
> as an optional dependency, or acknowledge that full Unicode support is
> taken for granted nowadays and use it by default.
>
> >
> > [1] http://site.icu-project.org/#TOC-Apache-Projects
> >
>
> Vincent
>

Re: FOP using ICU?

[Vincent Hennebert]

On 18/06/13 06:46, Glenn Adams wrote:
> Is there a reason FOP doesn't use ICU for determining line break
> boundaries? The FOP implementation of UAX14 (org.apache.fop.text.linebreak)
> seems to be out of date and basically unmaintained. According to [1], a
> number of Apache projects are using it, including PDFBox, Xalan, and Xerces.

I think the main reason in the past has been the size of the ICU4J jar
compared to FOP’s own jar:
http://markmail.org/thread/krkqlircefpuxlse

I guess the topic could be revisited today. We could consider adding it
as an optional dependency, or acknowledge that full Unicode support is
taken for granted nowadays and use it by default.

> 
> [1] http://site.icu-project.org/#TOC-Apache-Projects
> 

Vincent

[jira] [Updated] (FOP-2067) Region placement does not respect writing-mode

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2067:
-

Priority: Blocker
 Summary: Region placement does not respect writing-mode  (was: 
writing-mode on simple-page-master does not affect layout of regions)

> Region placement does not respect writing-mode
> --
>
> Key: FOP-2067
> URL: https://issues.apache.org/jira/browse/FOP-2067
> Project: Fop
>  Issue Type: Bug
>  Components: page-master/layout
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
> Attachments: SimplePageMasterRL.pdf, SimpleWritingModeRLTable.fo, 
> SimpleWritingModeRLTable.fo, SimpleWritingModeRLTable.pdf
>
>
> When writing-mode='tb-rl' is specified on fo:simple-page-master, the 
> fo:region-start area should appear on right, while the fo:region-end area 
> should appear on left.

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

[jira] [Updated] (FOP-2161) Unexpected page number formatting when writing-mode="lr"

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2161:
-

Priority: Blocker
 Summary: Unexpected page number formatting when writing-mode="lr"  (was: 
writing-mode="lr" an bidi-override etc)

> Unexpected page number formatting when writing-mode="lr"
> 
>
> Key: FOP-2161
> URL: https://issues.apache.org/jira/browse/FOP-2161
> Project: Fop
>  Issue Type: Bug
>  Components: page-master/layout
>Affects Versions: 1.1
> Environment: Operating System: All
> Platform: All
>Reporter: james quest
>Assignee: Glenn Adams
>Priority: Blocker
> Attachments: fo
>
>
> in left-to-right languages, we display 1 / 2 (i.e. page 1 of 2 pages).
> in right-to-left languages, it should also do 1 / 2, and it does if 
> 1 / 2 
> however, if it is  /  ref-id="endofdoc"/>,
> it displays (in right-to-left languages), 2 / 1 instead of 1 / 2
> a summary of different variations of this is below. they should all be 
> displayed the same for rl and rl, but in most cases it does not. (please find 
> attached fo)
> 1/2  
> renders as 1/2 for rl, 1/2 for lr 
> /
> renders as 2/1 for rl, 1/2 for lr 
> 
>   /
> 
> renders as 2/1 for rl, 1/2 for lr 
> 
>   /
> 
> renders as /21 for rl, 1/2 for lr 
> 
>   /
> 
> renders as /21 for rl, 1/2 for lr

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

[jira] [Updated] (FOP-2051) Need test cases: property value functions

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2051:
-

Priority: Blocker
 Summary: Need test cases: property value functions  (was: need test cases: 
property value functions)

> Need test cases: property value functions
> -
>
> Key: FOP-2051
> URL: https://issues.apache.org/jira/browse/FOP-2051
> Project: Fop
>  Issue Type: Improvement
>  Components: general
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> the following property value functions, defined in XSL-FO 1.1 5.10.4, do not 
> appear to have any test cases (or uses):
> inherited-property-value(NCname?)
> from-parent(NCname?)
> from-nearest-specified-value(NCname?)
> from-table-column(NCname?)

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

[jira] [Updated] (FOP-1822) Last resort font not supported

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-1822:
-

Priority: Blocker
 Summary: Last resort font not supported  (was: last resort font not 
supported)

> Last resort font not supported
> --
>
> Key: FOP-1822
> URL: https://issues.apache.org/jira/browse/FOP-1822
> Project: Fop
>  Issue Type: Bug
>  Components: fonts
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> during area generation, the mapping of characters to glyphs should make use 
> of a "last resort" font, e.g., see 
> http://www.unicode.org/policies/lastresortfont_eula.html, in order to render 
> characters that are otherwise unrenderable by the assigned font(s);
> suggest that FOP configuration file permit user to specify a last resort 
> font, and that area generation and/or font component(s) make use of this 
> information to map unrenderable characters to last resort glyphs;
> see also FOP-1180 (https://issues.apache.org/bugzilla/show_bug.cgi?id=39422)

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

[jira] [Updated] (FOP-2048) Need test cases: number functions

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2048:
-

Priority: Blocker
 Summary: Need test cases: number functions  (was: need test cases: number 
functions)

> Need test cases: number functions
> -
>
> Key: FOP-2048
> URL: https://issues.apache.org/jira/browse/FOP-2048
> Project: Fop
>  Issue Type: Improvement
>  Components: general
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> the following number functions, defined in XSL-FO 1.1 5.10.1, do not appear 
> to have any test cases (or uses):
> floor(numeric)
> ceiling(numeric)
> round(numeric)
> min(numeric,numeric)
> max(numeric,numeric)
> abs(numeric)

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

[jira] [Updated] (FOP-2053) Need implementation and test case: from-page-master-region function

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2053:
-

Priority: Blocker
 Summary: Need implementation and test case: from-page-master-region 
function  (was: need implementation and test case: from-page-master-region 
function)

> Need implementation and test case: from-page-master-region function
> ---
>
> Key: FOP-2053
> URL: https://issues.apache.org/jira/browse/FOP-2053
> Project: Fop
>  Issue Type: Improvement
>  Components: general
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> the following function, defined in XSL-FO 1.1 5.10.4, does not appear to have 
> any implementation or test case (or use):
> from-page-master-region(NCname?)

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

[jira] [Updated] (FOP-2052) Need implementation and test case: merge-property-values function

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2052:
-

Priority: Blocker
 Summary: Need implementation and test case: merge-property-values function 
 (was: need implementation and test case: merge-property-values function)

> Need implementation and test case: merge-property-values function
> -
>
> Key: FOP-2052
> URL: https://issues.apache.org/jira/browse/FOP-2052
> Project: Fop
>  Issue Type: Improvement
>  Components: general
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> the following function, defined in XSL-FO 1.1 5.10.4, does not appear to have 
> any implementation or test case (or use):
> merge-property-values(NCname?)

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

[jira] [Updated] (FOP-2049) Need test cases: color functions

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2049:
-

Priority: Blocker
 Summary: Need test cases: color functions  (was: need test cases: color 
functions)

> Need test cases: color functions
> 
>
> Key: FOP-2049
> URL: https://issues.apache.org/jira/browse/FOP-2049
> Project: Fop
>  Issue Type: Improvement
>  Components: general
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> the following color function, defined in XSL-FO 1.1 5.10.2, does not appear 
> to have any test case (or use):
> system-color(NCname)

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

[jira] [Updated] (FOP-2050) Need implementation and test case: system-font function

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2050:
-

Priority: Blocker
 Summary: Need implementation and test case: system-font function  (was: 
need implementation and test case: system-font function)

> Need implementation and test case: system-font function
> ---
>
> Key: FOP-2050
> URL: https://issues.apache.org/jira/browse/FOP-2050
> Project: Fop
>  Issue Type: Improvement
>  Components: general
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> the following font function, defined in XSL-FO 1.1 5.10.3, does not appear to 
> have any implementation or test case (or use):
> system-font(NCname,NCname?)

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

[jira] [Updated] (FOP-2204) Copy from PDF returns PUA characters

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2204:
-

Summary: Copy from PDF returns PUA characters  (was: copy from PDF returns 
PUA characters)

> Copy from PDF returns PUA characters
> 
>
> Key: FOP-2204
> URL: https://issues.apache.org/jira/browse/FOP-2204
> Project: Fop
>  Issue Type: Bug
>  Components: pdf
>Affects Versions: 1.1, trunk
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>
> when generating PDF that contains embedded fonts in which dynamic PUA 
> characters have been assigned, copy operations from a PDF viewer result in 
> those PUA characters being exported in a manner that precludes subsequent 
> correct display; this primarily affects the PDF output when complex script 
> features are used with fonts that do not have a CMAP entry for every 
> referenced glyph

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

[jira] [Updated] (FOP-2093) Explicit language may prevent gsub/gpos application

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2093:
-

Priority: Blocker
 Summary: Explicit language may prevent gsub/gpos application  (was: 
explicit language may prevent gsub/gpos application)

> Explicit language may prevent gsub/gpos application
> ---
>
> Key: FOP-2093
> URL: https://issues.apache.org/jira/browse/FOP-2093
> Project: Fop
>  Issue Type: Bug
>  Components: page-master/layout
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> Need to ensure that if author specifies language='dflt' or language='' 
> where '' effectively maps to the default language, but font does not list 
> '', then gsub/gpos features will be used if applicable.

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

[jira] [Updated] (FOP-2094) Explicit script may prevent gsub/gpos application

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2094:
-

Priority: Blocker
 Summary: Explicit script may prevent gsub/gpos application  (was: explicit 
script may prevent gsub/gpos application)

> Explicit script may prevent gsub/gpos application
> -
>
> Key: FOP-2094
> URL: https://issues.apache.org/jira/browse/FOP-2094
> Project: Fop
>  Issue Type: Bug
>  Components: page-master/layout
>Affects Versions: trunk
> Environment: Operating System: All
> Platform: All
>Reporter: Glenn Adams
>Assignee: Glenn Adams
>Priority: Blocker
>
> Need to ensure that if author specifies script='dflt' or script='' where 
> '' effectively maps to the default script, but font does not list '', 
> then gsub/gpos features will be used if applicable.

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

[jira] [Updated] (FOP-2249) Bidi hints (LRM, RLM) and joiners (ZWJ, ZWNJ) retained in formatting.

[Glenn Adams (JIRA)]

 [ 
https://issues.apache.org/jira/browse/FOP-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Glenn Adams updated FOP-2249:
-

  Component/s: page-master/layout
Affects Version/s: trunk
  Summary: Bidi hints (LRM, RLM) and joiners (ZWJ, ZWNJ) retained 
in formatting.  (was: Explicit bidi controls (RLM, LRM, ZWJ) retained in 
formatting.)

> Bidi hints (LRM, RLM) and joiners (ZWJ, ZWNJ) retained in formatting.
> -
>
> Key: FOP-2249
> URL: https://issues.apache.org/jira/browse/FOP-2249
> Project: Fop
>  Issue Type: Bug
>  Components: page-master/layout, ps
>Affects Versions: 1.1, trunk
> Environment: Windows 7 x64
>Reporter: Konrad Gajewski
>Assignee: Glenn Adams
> Attachments: arabic.fo, fop.xconf, test.pdf
>
>
> Hi, 
> I'm testing Arabic sentences mixed with English one.
> I found the following issue:
> When I'm trying to revert direction by U+200E, I'm getting the glyphs which 
> one is incorrect because should be nothing.
> For some Fonts I'm getting warning and I see "#" inside, for some of them 
> "incorrect character".
> .fo file:
> http://www.w3.org/1999/XSL/Format"; font-family="simpfxo">
>   
>  master-name="a4">
>margin-right="10mm" margin-left="10mm"/>
> 
>   
>   
> 
>   ‍ وكلما زادت معرفتك بها؛ زادت السلامة والمتعة التي 
> تحصل some text عليها خلال قيادتها. 
> ‏ البريد الإلكتروني ‎ Test
> 
>   
> 
> .fontconfig file
>  embedding-mode="full">
>   
> 
>  embedding-mode="full">
>   
>
>  embedding-mode="full">
>   
>  
>embed-url="file:///C:/Windows/Fonts/ScheherazadeRegOT.ttf" 
> embedding-mode="full">
>weight="normal"/>
> 
>embedding-mode="full">
>   
>  

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

[jira] [Commented] (FOP-2249) Explicit bidi controls (RLM, LRM, ZWJ) retained in formatting.

[Glenn Adams (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686470#comment-13686470
 ] 

Glenn Adams commented on FOP-2249:
--

As the author of the XSLT file template.xml, you are responsible for creating 
an XSLT that meets your needs. The input to FOP is an FO file. The XSLT 
function is there merely for convenience. Use a different tool to create the FO 
file if this simple convenience function doesn't meet your needs.

> Explicit bidi controls (RLM, LRM, ZWJ) retained in formatting.
> --
>
> Key: FOP-2249
> URL: https://issues.apache.org/jira/browse/FOP-2249
> Project: Fop
>  Issue Type: Bug
>  Components: ps
>Affects Versions: 1.1
> Environment: Windows 7 x64
>Reporter: Konrad Gajewski
>Assignee: Glenn Adams
> Attachments: arabic.fo, fop.xconf, test.pdf
>
>
> Hi, 
> I'm testing Arabic sentences mixed with English one.
> I found the following issue:
> When I'm trying to revert direction by U+200E, I'm getting the glyphs which 
> one is incorrect because should be nothing.
> For some Fonts I'm getting warning and I see "#" inside, for some of them 
> "incorrect character".
> .fo file:
> http://www.w3.org/1999/XSL/Format"; font-family="simpfxo">
>   
>  master-name="a4">
>margin-right="10mm" margin-left="10mm"/>
> 
>   
>   
> 
>   ‍ وكلما زادت معرفتك بها؛ زادت السلامة والمتعة التي 
> تحصل some text عليها خلال قيادتها. 
> ‏ البريد الإلكتروني ‎ Test
> 
>   
> 
> .fontconfig file
>  embedding-mode="full">
>   
> 
>  embedding-mode="full">
>   
>
>  embedding-mode="full">
>   
>  
>embed-url="file:///C:/Windows/Fonts/ScheherazadeRegOT.ttf" 
> embedding-mode="full">
>weight="normal"/>
> 
>embedding-mode="full">
>   
>  

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

[jira] [Commented] (FOP-2249) Explicit bidi controls (RLM, LRM, ZWJ) retained in formatting.

[Konrad Gajewski (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686456#comment-13686456
 ] 

Konrad Gajewski commented on FOP-2249:
--

Hi,
The workaround works only when you are using fo files.
Could you please provide me the solution for situation when I'm trying to 
generate based on xml file eq:
fop -xml test.xml -xsl template.xml -pdf test.pdf.
regards, Konrad

> Explicit bidi controls (RLM, LRM, ZWJ) retained in formatting.
> --
>
> Key: FOP-2249
> URL: https://issues.apache.org/jira/browse/FOP-2249
> Project: Fop
>  Issue Type: Bug
>  Components: ps
>Affects Versions: 1.1
> Environment: Windows 7 x64
>Reporter: Konrad Gajewski
>Assignee: Glenn Adams
> Attachments: arabic.fo, fop.xconf, test.pdf
>
>
> Hi, 
> I'm testing Arabic sentences mixed with English one.
> I found the following issue:
> When I'm trying to revert direction by U+200E, I'm getting the glyphs which 
> one is incorrect because should be nothing.
> For some Fonts I'm getting warning and I see "#" inside, for some of them 
> "incorrect character".
> .fo file:
> http://www.w3.org/1999/XSL/Format"; font-family="simpfxo">
>   
>  master-name="a4">
>margin-right="10mm" margin-left="10mm"/>
> 
>   
>   
> 
>   ‍ وكلما زادت معرفتك بها؛ زادت السلامة والمتعة التي 
> تحصل some text عليها خلال قيادتها. 
> ‏ البريد الإلكتروني ‎ Test
> 
>   
> 
> .fontconfig file
>  embedding-mode="full">
>   
> 
>  embedding-mode="full">
>   
>
>  embedding-mode="full">
>   
>  
>embed-url="file:///C:/Windows/Fonts/ScheherazadeRegOT.ttf" 
> embedding-mode="full">
>weight="normal"/>
> 
>embedding-mode="full">
>   
>  

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

[jira] [Commented] (FOP-2250) Arabic characters are not connected on PCL

[Konrad Gajewski (JIRA)]

[ 
https://issues.apache.org/jira/browse/FOP-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13686455#comment-13686455
 ] 

Konrad Gajewski commented on FOP-2250:
--

Luis, thank you very much for taking care of that. If you need any help to test 
it don't hesitate to contact me.

> Arabic characters are not connected on PCL
> --
>
> Key: FOP-2250
> URL: https://issues.apache.org/jira/browse/FOP-2250
> Project: Fop
>  Issue Type: Bug
>Affects Versions: 1.1
> Environment: Windows 7, x64
>Reporter: Konrad Gajewski
> Attachments: arabic.fo, arabic.pcl, arabic.pcl.pdf, fop.xconf, 
> PCL_issue.jpg, test2.pdf
>
>
> Hi, 
> When I try to print document on HP printer, Arabic characters are not printed 
> correctly.
> They should be connected.
> regards,
> Konrad Gajewski

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