[jira] [Closed] (FOP-2467) Syntax error in DOAP file release section; wrong bug-database URL

[Sebb (JIRA)]

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

Sebb closed FOP-2467.
-

Thanks, looks OK now

> Syntax error in DOAP file release section; wrong bug-database URL
> -
>
> Key: FOP-2467
> URL: https://issues.apache.org/jira/browse/FOP-2467
> Project: Fop
>  Issue Type: Bug
> Environment: 
> http://svn.apache.org/repos/asf/xmlgraphics/site/trunk/content/fop/doap.rdf
>Reporter: Sebb
>Assignee: Clay Leeds
>
> The DOAP still shows Bugzilla for the bug database.
> DOAP files can contain details of multiple release Versions, however each 
> must be listed in a separate release section, for example:
> 
>   
> Apache XYZ
> 2015-02-16
> 1.6.2
>   
> 
> 
>   
> Apache XYZ
> 2014-09-24
> 1.6.1
>   
> 
> Please can the project DOAP be corrected accordingly?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (FOP-2467) Syntax error in DOAP file release section; wrong bug-database URL

[Clay Leeds (JIRA)]

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

Clay Leeds resolved FOP-2467.
-
Resolution: Fixed
  Assignee: Clay Leeds

DOAP file updated. Please confirm.

> Syntax error in DOAP file release section; wrong bug-database URL
> -
>
> Key: FOP-2467
> URL: https://issues.apache.org/jira/browse/FOP-2467
> Project: Fop
>  Issue Type: Bug
> Environment: 
> http://svn.apache.org/repos/asf/xmlgraphics/site/trunk/content/fop/doap.rdf
>Reporter: Sebb
>Assignee: Clay Leeds
>
> The DOAP still shows Bugzilla for the bug database.
> DOAP files can contain details of multiple release Versions, however each 
> must be listed in a separate release section, for example:
> 
>   
> Apache XYZ
> 2015-02-16
> 1.6.2
>   
> 
> 
>   
> Apache XYZ
> 2014-09-24
> 1.6.1
>   
> 
> Please can the project DOAP be corrected accordingly?
> Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (FOP-2467) Syntax error in DOAP file release section; wrong bug-database URL

[Sebb (JIRA)]

Sebb created FOP-2467:
-

 Summary: Syntax error in DOAP file release section; wrong 
bug-database URL
 Key: FOP-2467
 URL: https://issues.apache.org/jira/browse/FOP-2467
 Project: Fop
  Issue Type: Bug
 Environment: 
http://svn.apache.org/repos/asf/xmlgraphics/site/trunk/content/fop/doap.rdf
Reporter: Sebb


The DOAP still shows Bugzilla for the bug database.

DOAP files can contain details of multiple release Versions, however each must 
be listed in a separate release section, for example:


  
Apache XYZ
2015-02-16
1.6.2
  


  
Apache XYZ
2014-09-24
1.6.1
  


Please can the project DOAP be corrected accordingly?

Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Float implementation - no reference in status.xml?

[Clay Leeds]

> Thanks! Definitely some catching up to do here!
> 
> Just tried it, and looks straightforward enough. Strange that I can edit the 
> page, but in edit mode, I still see yesterday's source? I mean, the change 
> you applied yesterday is not yet visible in the source code.
> 
> Sensors are detecting ruptures in the cyber-spacetime continuum... :-)

Yeah… That *is* strange… it shouldn’t be like that...

You can also make changes via CLI if you’d like, but this is pretty convenient… 
That said, there have been discussions about changing *again* to something 
else… I forget where that resolved, but I guess as long as we’re moving folks 
think we’re moving forward…

Cheers!

Clay Leeds  #  949-510-8993  @  the.webmaes...@gmail.com
"My religion is simple. My religion is kindness."
HH the Dalai Lama of Tibet

Re: Float implementation - no reference in status.xml?

[Andreas Delmelle]

> On 08 May 2015, at 18:58, Clay Leeds  wrote:
> 
> We are no longer using .xml files for documentation…
> 
> You need to follow the instructions here:
> 
> https://www.apache.org/dev/cms.html

Thanks! Definitely some catching up to do here!

Just tried it, and looks straightforward enough. Strange that I can edit the 
page, but in edit mode, I still see yesterday's source? I mean, the change you 
applied yesterday is not yet visible in the source code.

Sensors are detecting ruptures in the cyber-spacetime continuum... :-)



KR

Andreas

Re: Float implementation - no reference in status.xml?

[Clay Leeds]

We are no longer using .xml files for documentation…

You need to follow the instructions here:

https://www.apache.org/dev/cms.html 

Here’s some info about the change (the WHY):

https://www.apache.org/dev/infra-site.html 


Good luck!

Clay

> On May 8, 2015, at 9:53 AM, Andreas Delmelle  
> wrote:
> 
> Hi all
> 
> Something that caught my eye: while browsing status.xml, I could not find a 
> reference to the basic side-float implementation that was merged into trunk a 
> while back.
> 
> Maybe it’s just me, but this is precisely the kind of enhancement I would 
> want to see advertised in a future release. Get as much people as possible to 
> try it out and report back on quirks, strange side-effects, etc.
> 
> An oversight? Or are we not actively maintaining that file anymore?
> 
> 
> KR
> 
> Andreas

Float implementation - no reference in status.xml?

[Andreas Delmelle]

Hi all

Something that caught my eye: while browsing status.xml, I could not find a 
reference to the basic side-float implementation that was merged into trunk a 
while back.

Maybe it’s just me, but this is precisely the kind of enhancement I would want 
to see advertised in a future release. Get as much people as possible to try it 
out and report back on quirks, strange side-effects, etc.

An oversight? Or are we not actively maintaining that file anymore?


KR

Andreas

[jira] [Updated] (FOP-2466) Improve output for pre-hyphenated text with SHY combined with hyphenation properties

[Andreas L. Delmelle (JIRA)]

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

Andreas L. Delmelle updated FOP-2466:
-
Description: 
When processing a FO file that contains pre-hyphenated text, using 
soft-hyphens, FOP's hyphenation does not yield usable results.

>From the corresponding thread on fop-users@:

---
The accumulated sequence of characters since the previous break opportunity is 
taken to be a 'word', which may or may not end in a hyphen. If the latter is 
true, a specific sequence of elements is glued to the word-box, to prevent a 
break before SHY and make sure that it is properly rendered, i.e. only counts 
if the break occurs right after.

As hyphenation by FOP itself is applied at a higher level, when all layout 
elements for a whole paragraph have been collected, that SHY sequence is seen 
as a word boundary. That is, that part of the algorithm just accumulates the 
text for ‘uninterrupted' sequences of word-boxes, and feeds those pieces to the 
hyphenator. The real intention is to apply hyphenation across any nested 
fo:inlines. ‘Uninterrupted’ means that auxiliary elements, generated for border 
or padding are explicitly *not* considered as word boundaries. The sequence 
generated for SHY contains two non-auxiliary elements, as if it were a space. 
Perhaps, just to ensure that that position in the layout always leads to a 
character that is visibly rendered.

In case of pre-hyphenated text, this has the unintended effect of restricting 
the input for the hyphenator to parts of words, which is basically meaningless 
(and wasteful).
---

Amongst others, this leads to the "hyphenation-ladder-count" property having 
seemingly no effect.

Note - At this point, I believe the behaviour is not necessarily incorrect. I 
am also thinking that it would be correct to ignore hyphenation-ladder-count in 
case hyphenation="false".

Initial idea for a fix: 
Make sure that the SHY sequence is not treated as a word boundary in LineLM 
when accumulating text for boxes generated by the TextLMs. Once done, we should 
then be able to check for each hyphenation point that FOP itself calculates, 
whether there is already an explicit SHY present at that same point. In that 
case, we can just do nothing (= leave the SHY in place).

  was:
When processing a FO file that contains pre-hyphenated text, using 
soft-hyphens, FOP's hyphenation does not yield usable results.

>From the corresponding thread on fop-users@:

... internally for FOP, [t]he accumulated sequence of characters since the 
previous break opportunity is taken to be a 'word', which may or may not end in 
a hyphen. If the latter is true, a specific sequence of elements is glued to 
the word-box, to prevent a break before SHY and make sure that it is properly 
rendered, i.e. only counts if the break occurs right after.

As hyphenation by FOP itself is applied at a higher level, when all layout 
elements for a whole paragraph have been collected, that SHY sequence is seen 
as a word boundary. That is, that part of the algorithm just accumulates the 
text for ‘uninterrupted' sequences of word-boxes, and feeds those pieces to the 
hyphenator. The real intention is to apply hyphenation across any nested 
fo:inlines. ‘Uninterrupted’ means that auxiliary elements, generated for border 
or padding are explicitly *not* considered as word boundaries. The sequence 
generated for SHY contains two non-auxiliary elements, as if it were a space. 
Perhaps, just to ensure that that position in the layout always leads to a 
character that is visibly rendered.

In case of pre-hyphenated text, this has the unintended effect of restricting 
the input for the hyphenator to parts of words, which is basically meaningless 
(and wasteful).

Amongst others, this leads to the "hyphenation-ladder-count" property having 
seemingly no effect.

Note - At this point, I believe the behaviour is not necessarily incorrect. I 
am also thinking that it would be correct to ignore hyphenation-ladder-count in 
case hyphenation="false".

Initial idea for a fix: 
Make sure that the SHY sequence is not treated as a word boundary in LineLM 
when accumulating text for boxes generated by the TextLMs. Once done, we should 
then be able to check for each hyphenation point that FOP itself calculates, 
whether there is already an explicit SHY present at that same point. In that 
case, we can just do nothing (= leave the SHY in place).


> Improve output for pre-hyphenated text with SHY combined with hyphenation 
> properties
> 
>
> Key: FOP-2466
> URL: https://issues.apache.org/jira/browse/FOP-2466
> Project: Fop
>  Issue Type: Improvement
>  Components: layout/line
>Affects Versions: 1.1
>Reporter: Andreas L. Delmelle
>Priority: Minor
>   

[jira] [Created] (FOP-2466) Improve output for pre-hyphenated text with SHY combined with hyphenation properties

[Andreas L. Delmelle (JIRA)]

Andreas L. Delmelle created FOP-2466:


 Summary: Improve output for pre-hyphenated text with SHY combined 
with hyphenation properties
 Key: FOP-2466
 URL: https://issues.apache.org/jira/browse/FOP-2466
 Project: Fop
  Issue Type: Improvement
  Components: layout/line
Affects Versions: 1.1
Reporter: Andreas L. Delmelle
Priority: Minor


When processing a FO file that contains pre-hyphenated text, using 
soft-hyphens, FOP's hyphenation does not yield usable results.

>From the corresponding thread on fop-users@:

... internally for FOP, [t]he accumulated sequence of characters since the 
previous break opportunity is taken to be a 'word', which may or may not end in 
a hyphen. If the latter is true, a specific sequence of elements is glued to 
the word-box, to prevent a break before SHY and make sure that it is properly 
rendered, i.e. only counts if the break occurs right after.

As hyphenation by FOP itself is applied at a higher level, when all layout 
elements for a whole paragraph have been collected, that SHY sequence is seen 
as a word boundary. That is, that part of the algorithm just accumulates the 
text for ‘uninterrupted' sequences of word-boxes, and feeds those pieces to the 
hyphenator. The real intention is to apply hyphenation across any nested 
fo:inlines. ‘Uninterrupted’ means that auxiliary elements, generated for border 
or padding are explicitly *not* considered as word boundaries. The sequence 
generated for SHY contains two non-auxiliary elements, as if it were a space. 
Perhaps, just to ensure that that position in the layout always leads to a 
character that is visibly rendered.

In case of pre-hyphenated text, this has the unintended effect of restricting 
the input for the hyphenator to parts of words, which is basically meaningless 
(and wasteful).

Amongst others, this leads to the "hyphenation-ladder-count" property having 
seemingly no effect.

Note - At this point, I believe the behaviour is not necessarily incorrect. I 
am also thinking that it would be correct to ignore hyphenation-ladder-count in 
case hyphenation="false".

Initial idea for a fix: 
Make sure that the SHY sequence is not treated as a word boundary in LineLM 
when accumulating text for boxes generated by the TextLMs. Once done, we should 
then be able to check for each hyphenation point that FOP itself calculates, 
whether there is already an explicit SHY present at that same point. In that 
case, we can just do nothing (= leave the SHY in place).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)