[jira] [Commented] (FOP-2515) [PATCH] Use default value for keep-with-next if inherit and parent has no explicit value
[
https://issues.apache.org/jira/browse/FOP-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804764#comment-17804764
]
Björn Kautler commented on FOP-2515:
I tested again with latest {{main}} and it still happens.
The patch is still valid for latest {{main}} commit.
> [PATCH] Use default value for keep-with-next if inherit and parent has no
> explicit value
>
>
> Key: FOP-2515
> URL: https://issues.apache.org/jira/browse/FOP-2515
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2515.patch
>
>
> If I have keep-with-next="inherit" on a fo:block, but no explicit value on
> the parent FO, FOP tells me this with {{keep-with-next="inherit" on fo:block,
> but no explicit value found on the parent FO.}}.
> I'd expect that inherit just inherits what is used on the parent, no matter
> whether this is explicitly set or not.
> So if the parent is using the default value, the one that inherits should
> simply also use the default value and not output anyhting.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3157) PCL fonts are printed as numbers and punctuation
[ https://issues.apache.org/jira/browse/FOP-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804762#comment-17804762 ] Maria commented on FOP-3157: Hello Simon, I would like to add, that I managed to print well a PCL with embedded fonts with lp command on LINUX. Wish you a nice day! Kind regards, Maria > PCL fonts are printed as numbers and punctuation > > > Key: FOP-3157 > URL: https://issues.apache.org/jira/browse/FOP-3157 > Project: FOP > Issue Type: Bug >Affects Versions: 2.9 >Reporter: Maria >Priority: Major > Attachments: TestPclEmbededFont.fo, TestPclEmbededFont.pcl, > embeddFontOneLine-1.fo, embeddFontOneLine.fo, > embeddFontOneLineSimpleProject-1.pcl, embeddFontOneLineSimpleProject.pcl, > fop.xconf, image-2023-11-01-18-58-56-405.png, > image-2023-11-01-18-59-28-380.png, image-2023-11-01-19-01-44-174.png, > image-2023-11-01-19-05-44-582.png, image-2023-11-01-19-07-21-317.png, > image-2023-11-02-19-36-16-242.png, image-2023-11-02-19-37-25-203.png, > image-2023-11-02-19-38-00-072.png, image-2023-11-02-19-39-17-431.png, > image-2023-11-02-19-40-14-808.png, image-2023-11-09-11-39-34-302.png, > image-2023-11-09-11-41-17-089.png, printedTestEmbededPclFont.png > > > Hello, > > Can you, please, help with embedded fonts in PCL. > > Produced with Apache fop 2.9 (embedded in app) a PCL file with embedded fonts. > When printed on my HP Laser jet P2055dn, all symbols are represented with > numbers and punctuation. > In Red Titan it is almost well represented - it has most of the symbols: > !image-2023-11-01-18-59-28-380.png|width=667,height=226! > > And Fonts are in the document: > !image-2023-11-01-19-01-44-174.png|width=655,height=141! > > However, in PCL Paraphernalia (print analysis tool), symbols are represented > as > |90af|Data| |3#4+ 5#4+
[jira] [Comment Edited] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804755#comment-17804755
]
Björn Kautler edited comment on FOP-2522 at 1/9/24 2:43 PM:
Ok [~cbowditch] I tested again with latest {{main}} and it still happens.
I attached now a fo file that demonstrates the issue.
The patch is still valid for latest {{main}} commit.
was (Author: vampire):
Ok [~cbowditch] I tested again with latest {{main}} and it still happens.
I attached now a fo file that demonstrates the issue.
The patch is still valid for latest `main` commit.
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804755#comment-17804755
]
Björn Kautler edited comment on FOP-2522 at 1/9/24 2:42 PM:
Ok [~cbowditch] I tested again with latest {{main}} and it still happens.
I attached now a fo file that demonstrates the issue.
The patch is still valid for latest `main` commit.
was (Author: vampire):
Ok [~cbowditch] I tested against with latest {{main}} and it still happens.
I attached now a fo file that demonstrates the issue.
The patch is still valid for latest `main` commit.
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804755#comment-17804755
]
Björn Kautler commented on FOP-2522:
Ok [~cbowditch] I tested against with latest {{main}} and it still happens.
I attached now a fo file that demonstrates the issue.
The patch is still valid for latest `main` commit.
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (FOP-2522) [PATCH] Soft hyphens in front of some characters are transformed to hyphen-minus
[
https://issues.apache.org/jira/browse/FOP-2522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Björn Kautler updated FOP-2522:
---
Attachment: issue-2522.fo
> [PATCH] Soft hyphens in front of some characters are transformed to
> hyphen-minus
>
>
> Key: FOP-2522
> URL: https://issues.apache.org/jira/browse/FOP-2522
> Project: FOP
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Björn Kautler
>Priority: Major
> Attachments: issue-2522.fo, issue-2522.patch
>
>
> If you have a verbatim block like {{}} in DocBook, the
> DocBook XSL stylesheets insert many soft hypens
> (http://decodeunicode.org/u+00AD) into the content to show where the
> FO-processor may insert linebreaks. By default after spaces and non-breakable
> spaces, but configurable also after arbitrary other characters.
> Unfortunately it seems FOP does not handle the soft hyphens correctly,
> depending on the character that follows it. Soft Hyphens in front of some
> characters are transformed to hyphen-minus, no matter what
> hyphenation-characters is configured and even if the occurence is within a
> line and not at line break.
> I've observed this behaviour with soft hyphens in front of apostrophe
> (http://decodeunicode.org/u+0027), quotation mark
> (http://decodeunicode.org/u+0022), hyphen-minus
> (http://decodeunicode.org/u+002D) and full stop
> (http://decodeunicode.org/u+002E)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
