[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=17807787#comment-17807787
]
Björn Kautler edited comment on FOP-2522 at 1/17/24 3:54 PM:
-
Look at the screenshots I had in my last comment.
In the upper example in each screenshot it is only not shown on line-end - and
that is correct - as the {{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still is shown even with my patch.
That is on line-end where the word was split due to SHY.
was (Author: vampire):
Look at the screenshots I had in my last comment.
In the upper example in each screenshot it is only not shown on line-end - and
that is correct - as the {{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still shown even with my patch.
That is on line-end where the word was split due to SHY.
> [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: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, 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=17807787#comment-17807787
]
Björn Kautler edited comment on FOP-2522 at 1/17/24 3:54 PM:
-
Look at the screenshots I had in my last comment.
In the upper example in each screenshot it is only not shown on line-end - and
that is correct - as the {{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still shown even with my patch.
That is on line-end where the word was split due to SHY.
was (Author: vampire):
Look at the screenshots I had in my last comment.
In the upper example in each screenshot it is only not shown on line-end
correctly as the {{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still shown even with my patch.
That is on line-end where the word was split due to SHY.
> [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: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, 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-3135) SVG content is displayed on a single line without spaces
[
https://issues.apache.org/jira/browse/FOP-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807756#comment-17807756
]
João André Gonçalves commented on FOP-3135:
---
[~julienlacour31] I got the same issue as you with a different font. It looks
like a separate issue, since the coordinates are completely ignored now.
> SVG content is displayed on a single line without spaces
>
>
> Key: FOP-3135
> URL: https://issues.apache.org/jira/browse/FOP-3135
> Project: FOP
> Issue Type: Bug
> Components: image/svg
>Reporter: Julien Lacour
>Priority: Minor
> Attachments: MI-Calibri-test.pdf, MI-out-patch.pdf, MI-out.pdf,
> MI-test.fo, MI-tspan.svg, MI.patch, WIP-out.pdf, WIP.patch, tspan.svg
>
>
> We have found an issue in FOP when transforming PDFs with SVGs containing
> with multiple @x and/or @y attributes values.
> The problem is located in
> org.apache.fop.svg.PDFTextPainter.writeGlyphs(FOPGVTGlyphVector,
> GeneralPath), the positions given by x and y are never used when set.
> A possible fix for this issue is the following:
> {code:java}
> for (int i = 0, n = gv.getNumGlyphs(); i < n; i++) {
> int gc = gv.getGlyphCode(i);
> int[] pa = ((i > dp.length) || (dp[i] == null)) ?
> paZero : dp[i];
> if (gv.getGlyphPosition(i) != null) {
> Point2D gp = gv.getGlyphPosition(i);
> double x= gp.getX() - initialPos.getX();
> double y= -(gp.getY() - initialPos.getY());
> double xd = x - xoLast;
> double yd = y - yoLast;
> textUtil.writeTd(xd, yd);
> textUtil.writeTj((char) gc, true, false);
> xc = x + pa[2];
> yc = y + pa[3];
> xoLast = x;
> yoLast = y;
> } else {
> double xo = xc + pa[0];
> double yo = yc + pa[1];
> double xa = f.getWidth(gc);
> double ya = 0;
> double xd = (xo - xoLast) / 1000f;
> double yd = (yo - yoLast) / 1000f;
>
> textUtil.writeTd(xd, yd);
> textUtil.writeTj((char) gc, true, false);
> xc += xa + pa[2];
> yc += ya + pa[3];
> xoLast = xo;
> yoLast = yo;
> }
> }
> {code}
> I also attached an example for testing, it can be opened in Batik for
> comparison.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FOP-3135) SVG content is displayed on a single line without spaces
[
https://issues.apache.org/jira/browse/FOP-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807782#comment-17807782
]
Julien Lacour commented on FOP-3135:
[~jgoncalves] would you like me to put a separate issue and link them together,
or you prefer doing it?
> SVG content is displayed on a single line without spaces
>
>
> Key: FOP-3135
> URL: https://issues.apache.org/jira/browse/FOP-3135
> Project: FOP
> Issue Type: Bug
> Components: image/svg
>Reporter: Julien Lacour
>Priority: Minor
> Attachments: MI-Calibri-test.pdf, MI-out-patch.pdf, MI-out.pdf,
> MI-test.fo, MI-tspan.svg, MI.patch, WIP-out.pdf, WIP.patch, tspan.svg
>
>
> We have found an issue in FOP when transforming PDFs with SVGs containing
> with multiple @x and/or @y attributes values.
> The problem is located in
> org.apache.fop.svg.PDFTextPainter.writeGlyphs(FOPGVTGlyphVector,
> GeneralPath), the positions given by x and y are never used when set.
> A possible fix for this issue is the following:
> {code:java}
> for (int i = 0, n = gv.getNumGlyphs(); i < n; i++) {
> int gc = gv.getGlyphCode(i);
> int[] pa = ((i > dp.length) || (dp[i] == null)) ?
> paZero : dp[i];
> if (gv.getGlyphPosition(i) != null) {
> Point2D gp = gv.getGlyphPosition(i);
> double x= gp.getX() - initialPos.getX();
> double y= -(gp.getY() - initialPos.getY());
> double xd = x - xoLast;
> double yd = y - yoLast;
> textUtil.writeTd(xd, yd);
> textUtil.writeTj((char) gc, true, false);
> xc = x + pa[2];
> yc = y + pa[3];
> xoLast = x;
> yoLast = y;
> } else {
> double xo = xc + pa[0];
> double yo = yc + pa[1];
> double xa = f.getWidth(gc);
> double ya = 0;
> double xd = (xo - xoLast) / 1000f;
> double yd = (yo - yoLast) / 1000f;
>
> textUtil.writeTd(xd, yd);
> textUtil.writeTj((char) gc, true, false);
> xc += xa + pa[2];
> yc += ya + pa[3];
> xoLast = xo;
> yoLast = yo;
> }
> }
> {code}
> I also attached an example for testing, it can be opened in Batik for
> comparison.
--
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=17807787#comment-17807787
]
Björn Kautler commented on FOP-2522:
Look at the screenshots I had in my last comment.
In the upper examples it is only not shown on line-end correctly as the
{{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still shown even with my patch.
That is on line-end where the word was split due to SHY.
> [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: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, 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=17807787#comment-17807787
]
Björn Kautler edited comment on FOP-2522 at 1/17/24 3:53 PM:
-
Look at the screenshots I had in my last comment.
In the upper example in each screenshot it is only not shown on line-end
correctly as the {{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still shown even with my patch.
That is on line-end where the word was split due to SHY.
was (Author: vampire):
Look at the screenshots I had in my last comment.
In the upper examples it is only not shown on line-end correctly as the
{{hyphenation-character}} is set to empty value.
To reduce your confusion and uncertainty, I added the lower example, where you
see that where it should be shown it still shown even with my patch.
That is on line-end where the word was split due to SHY.
> [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: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, 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=17807780#comment-17807780
]
Chris Bowditch commented on FOP-2522:
-
Ok so that's explains why they can't use ZWSP, but SHY still needs to be drawn
when it is actually used to hyphenate a word, and your patch always excludes it
from the output so I still don't think the patch is the correct solution.
Instead the logic around when the SHY is shown needs to be debugged to
understand why its not always working
> [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: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, 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-3135) SVG content is displayed on a single line without spaces
[
https://issues.apache.org/jira/browse/FOP-3135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17807785#comment-17807785
]
João André Gonçalves commented on FOP-3135:
---
It's all related so it's fine they stay together.
> SVG content is displayed on a single line without spaces
>
>
> Key: FOP-3135
> URL: https://issues.apache.org/jira/browse/FOP-3135
> Project: FOP
> Issue Type: Bug
> Components: image/svg
>Reporter: Julien Lacour
>Priority: Minor
> Attachments: MI-Calibri-test.pdf, MI-out-patch.pdf, MI-out.pdf,
> MI-test.fo, MI-tspan.svg, MI.patch, WIP-out.pdf, WIP.patch, tspan.svg
>
>
> We have found an issue in FOP when transforming PDFs with SVGs containing
> with multiple @x and/or @y attributes values.
> The problem is located in
> org.apache.fop.svg.PDFTextPainter.writeGlyphs(FOPGVTGlyphVector,
> GeneralPath), the positions given by x and y are never used when set.
> A possible fix for this issue is the following:
> {code:java}
> for (int i = 0, n = gv.getNumGlyphs(); i < n; i++) {
> int gc = gv.getGlyphCode(i);
> int[] pa = ((i > dp.length) || (dp[i] == null)) ?
> paZero : dp[i];
> if (gv.getGlyphPosition(i) != null) {
> Point2D gp = gv.getGlyphPosition(i);
> double x= gp.getX() - initialPos.getX();
> double y= -(gp.getY() - initialPos.getY());
> double xd = x - xoLast;
> double yd = y - yoLast;
> textUtil.writeTd(xd, yd);
> textUtil.writeTj((char) gc, true, false);
> xc = x + pa[2];
> yc = y + pa[3];
> xoLast = x;
> yoLast = y;
> } else {
> double xo = xc + pa[0];
> double yo = yc + pa[1];
> double xa = f.getWidth(gc);
> double ya = 0;
> double xd = (xo - xoLast) / 1000f;
> double yd = (yo - yoLast) / 1000f;
>
> textUtil.writeTd(xd, yd);
> textUtil.writeTj((char) gc, true, false);
> xc += xa + pa[2];
> yc += ya + pa[3];
> xoLast = xo;
> yoLast = yo;
> }
> }
> {code}
> I also attached an example for testing, it can be opened in Batik for
> comparison.
--
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=17807729#comment-17807729
]
Björn Kautler commented on FOP-2522:
Probably because that is exactly what a soft hyphen is for?
[https://en.wikipedia.org/wiki/Soft_hyphen]
{quote}In computing and typesetting, a *soft hyphen* [...] or *syllable hyphen*
[...], abbreviated {*}SHY{*}, is a code point reserved in some [coded character
sets|https://en.wikipedia.org/wiki/Coded_character_set] for the purpose of
breaking words across lines by inserting visible
[hyphens|https://en.wikipedia.org/wiki/Hyphen] if they fall on the line end but
remain invisible within the line
{quote}
So it should never be shown within a line, but when needed at that spot the
text can be split at the line-end and the hyphenation character shown.
With a ZWSP it would probably break, but not show the hyphenation character.
Also with a ZWSP other tools would consider left and right part two words,
while with "SHY" it really is one word with markers where the word could be
split at line-end.
If you add a bit more to the test like a very long line of "asdf" followed by
"SHY" repeated wihtout other spaces, so {{asdfasdfasdf...}} and then
duplicate the {{fo:block}} and in the second set the {{hyphenation-character}}
attribute to value {{/}} mainly for demonstration purpose, this is the intended
outcome that is also produced with my patch:
!image-2024-01-17-14-42-53-377.png!
while without my patch the actual and undesired outcome is:
!image-2024-01-17-14-46-46-565.png!
So yes, I think it is the right to always suppress it like I did, as it should
be never correct to show a hyphen-minus in place of a SHY which is only a "you
can break the word here" marker.
> [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=17807729#comment-17807729
]
Björn Kautler edited comment on FOP-2522 at 1/17/24 1:49 PM:
-
Probably because that is exactly what a soft hyphen is for?
[https://en.wikipedia.org/wiki/Soft_hyphen]
{quote}In computing and typesetting, a *soft hyphen* [...] or *syllable hyphen*
[...], abbreviated {*}SHY{*}, is a code point reserved in some [coded character
sets|https://en.wikipedia.org/wiki/Coded_character_set] for the purpose of
breaking words across lines by inserting visible
[hyphens|https://en.wikipedia.org/wiki/Hyphen] if they fall on the line end but
remain invisible within the line
{quote}
So it should never be shown within a line, but when needed at that spot the
text can be split at the line-end and the hyphenation character shown.
With a ZWSP it would probably break, but not show the hyphenation character.
Also with a ZWSP other tools would consider left and right part two words,
while with "SHY" it really is one word with markers where the word could be
split at line-end.
If you add a bit more to the test like a very long line of "asdf" followed by
"SHY" repeated wihtout other spaces, so {{asdfasdfasdf...}} and then
duplicate the {{fo:block}} and in the second set the {{hyphenation-character}}
attribute to value {{/}} mainly for demonstration purpose, this is the intended
outcome that is also produced with my patch:
!image-2024-01-17-14-48-50-945.png!
while without my patch the actual and undesired outcome is:
!image-2024-01-17-14-49-08-309.png!
So yes, I think it is the right to always suppress it like I did, as it should
be never correct to show a hyphen-minus in place of a SHY which is only a "you
can break the word here" marker.
was (Author: vampire):
Probably because that is exactly what a soft hyphen is for?
[https://en.wikipedia.org/wiki/Soft_hyphen]
{quote}In computing and typesetting, a *soft hyphen* [...] or *syllable hyphen*
[...], abbreviated {*}SHY{*}, is a code point reserved in some [coded character
sets|https://en.wikipedia.org/wiki/Coded_character_set] for the purpose of
breaking words across lines by inserting visible
[hyphens|https://en.wikipedia.org/wiki/Hyphen] if they fall on the line end but
remain invisible within the line
{quote}
So it should never be shown within a line, but when needed at that spot the
text can be split at the line-end and the hyphenation character shown.
With a ZWSP it would probably break, but not show the hyphenation character.
Also with a ZWSP other tools would consider left and right part two words,
while with "SHY" it really is one word with markers where the word could be
split at line-end.
If you add a bit more to the test like a very long line of "asdf" followed by
"SHY" repeated wihtout other spaces, so {{asdfasdfasdf...}} and then
duplicate the {{fo:block}} and in the second set the {{hyphenation-character}}
attribute to value {{/}} mainly for demonstration purpose, this is the intended
outcome that is also produced with my patch:
!image-2024-01-17-14-42-53-377.png!
while without my patch the actual and undesired outcome is:
!image-2024-01-17-14-46-46-565.png!
So yes, I think it is the right to always suppress it like I did, as it should
be never correct to show a hyphen-minus in place of a SHY which is only a "you
can break the word here" marker.
> [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: image-2024-01-17-14-48-50-945.png,
> image-2024-01-17-14-49-08-309.png, 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
