[xep-support] Re: Hyphenation issue in table

From: Darren Munt <darrenm_at_ADDRESS_REMOVED>
Date: Mon Apr 10 2017 - 14:11:43 PDT

Thank you Kevin, that is what I was after yesterday. Until now I had never heard of those hyphenation attributes. This is why I posted in the first place.

From: Kevin Brown [mailto:kevin@renderx.com]
Sent: Tuesday, 11 April 2017 4:52 AM
To: Darren Munt <darrenm@ardex.com.au>
Cc: xep-support@renderx.com
Subject: RE: [xep-support] Re: Hyphenation issue in table

Well, there will always be room on the next line, it is blank at that moment.
That said, maybe you rule better stated is that you do not want words shorter than "X" characters to be broken.
Let's say that is 8 (control is 7) ... so splitting this between push and remain counts like this:

        <fo:flow flow-name="xsl-region-body">
            <fo:block-container width="0.65in" hyphenate="true" hyphenation-push-character-count="4" hyphenation-remain-character-count="4">
                <fo:block>Hyper-awareness</fo:block>
                <fo:block>Flow control</fo:block>
            </fo:block-container>
        </fo:flow>

Yields this:

[cid:image001.png@01D2B292.DF728780]

Kevin Brown
RenderX

From: Darren Munt [mailto:darrenm@ardex.com.au]
Sent: Sunday, April 09, 2017 9:08 PM
To: kevin@renderx.com<mailto:kevin@renderx.com>
Subject: RE: [xep-support] Re: Hyphenation issue in table

I've tried both actually. If I enter the text via my keyboard, then I get 002D. Or I can use the entity &#x2010;. Neither gives me a word break at the hyphen.

From: Kevin Brown [mailto:kevin@renderx.com]
Sent: Monday, 10 April 2017 1:27 PM
To: Darren Munt <darrenm@ardex.com.au<mailto:darrenm@ardex.com.au>>
Subject: RE: [xep-support] Re: Hyphenation issue in table

Are the u+2010 characters in your data? Or u+002D?

From: Darren Munt [mailto:darrenm@ardex.com.au]
Sent: Sunday, April 09, 2017 8:07 PM
To: kevin@renderx.com<mailto:kevin@renderx.com>
Subject: RE: [xep-support] Re: Hyphenation issue in table

The only thing I disagree on is that it should also allow line-breaking on a hard hyphen (U+2010), which it apparently does not.

From: Kevin Brown [mailto:kevin@renderx.com]
Sent: Monday, 10 April 2017 12:57 PM
To: Darren Munt <darrenm@ardex.com.au<mailto:darrenm@ardex.com.au>>
Subject: RE: [xep-support] Re: Hyphenation issue in table

1) Read here for more information: http://www.renderx.com/reference.html#Linguistic_LineBreaking

2) As a go-forward formatter, we don't look behind nor forward unless we have to (for performance reasons). Making a decision whether we should put the whole part of a word on the next line or hyphenate it on the current line would require that ... because the word may be supercalifragilisticexpialidocious and require more than two lines or three ... or it may be a URL that requires 10 lines. There is no guessing at that.

Kevin

From: Darren Munt [mailto:darrenm@ardex.com.au]
Sent: Sunday, April 09, 2017 7:39 PM
To: kevin@renderx.com<mailto:kevin@renderx.com>
Subject: RE: [xep-support] Re: Hyphenation issue in table

OK, I thought I had made that clear but obviously not. The word is hyphenated in the original text: hyper-awareness. With hyphenation off, RenderX does not break on the hyphen, which as far as I am concerned is unexpected behaviour. Instead it chooses to cram it all together so that it is illegible.

I believe that it is reasonable for a normal hyphen to be considered a valid word boundary and therefore a candidate for line breaking. The reason for the existence of the non-breaking hyphen U+2011 is so that you can control the situation you refer to below in your +/- currency example.

When you do switch hyphenation on, it does break at the hyphen but it also breaks words unnecessarily. Again this is unexpected behaviour from my point of view, since the engine seems capable of formatting "Flow control" over two lines without hyphenation switched on. I understand why it is doing it - because it is finding the soft hyphen in the middle of "control" - but choosing to break there rather than the actual space between the words is not intuitive. I know these things are difficult.

We can't insert zero-width breaking spaces to trick RenderX into breaking there because the document is translated into many languages by other parties and it would not be practical to handle it that way. I found that recommendation of yours when searching for a solution but it is not satisfactory. So I will have to work out something else. I guess I will have to do a search and replace on hyphens in my code before transforming it.

From: Kevin Brown [mailto:kevin@renderx.com]
Sent: Monday, 10 April 2017 12:20 PM
To: Darren Munt <darrenm@ardex.com.au<mailto:darrenm@ardex.com.au>>; 'RenderX Community Support List' <xep-support@renderx.com<mailto:xep-support@renderx.com>>
Subject: RE: [xep-support] Re: Hyphenation issue in table

Darren:

Does you content have "Hyperawaremess" or "Hyper-awareness" in it? We do not see your content when you post snippets of output.
If you are saying it has the latter then you need to insert a zero-width breaking space as that is not a natural breaking place.
Otherwise you would get this:

You owe -
$25,000 to
your account.

Which would be hard to determine is you owe -$25,000 or $25,000

Kevin

From: Darren Munt [mailto:darrenm@ardex.com.au]
Sent: Sunday, April 09, 2017 7:03 PM
To: RenderX Community Support List <xep-support@renderx.com<mailto:xep-support@renderx.com>>; kevin@renderx.com<mailto:kevin@renderx.com>
Subject: RE: [xep-support] Re: Hyphenation issue in table

In fact, why doesn't it just break on the hyphen without switching hyphenation on in the first place? It's not a non-breaking hyphen. Microsoft Word handles it OK:

[cid:image002.png@01D2B292.DF728780]
This is the behaviour I'm after. Can I make XEP do that?

From: Xep-support [mailto:xep-support-bounces@renderx.com] On Behalf Of Darren Munt
Sent: Monday, 10 April 2017 11:50 AM
To: kevin@renderx.com<mailto:kevin@renderx.com>; RenderX Community Support List <xep-support@renderx.com<mailto:xep-support@renderx.com>>
Subject: [xep-support] Re: Hyphenation issue in table

Thanks Kevin that is really helpful. Are you having a bad day?

Why does it hyphenate "control"? There is no need for it to do so. It fits perfectly well with hyphenation off.

From: Xep-support [mailto:xep-support-bounces@renderx.com] On Behalf Of Kevin Brown
Sent: Monday, 10 April 2017 11:45 AM
To: 'RenderX Community Support List' <xep-support@renderx.com<mailto:xep-support@renderx.com>>
Subject: [xep-support] Re: Hyphenation issue in table

Invent you own hyphenation dictionary with the special occurrences of your words that you do not want hyphenated.

It is not like the software can guess what you want hyphenated and not.

Kevin Brown
Executive Vice President, Sales & Marketing RenderX, Inc.
(650) 327-1000 Direct
(650) 328-8008 Fax
(925) 395-1772 Mobile
skype:kbrown01
kevin@renderx.com<mailto:kevin@renderx.com>
sales@renderx.com<mailto:sales@renderx.com>
http://www.renderx.com<http://www.renderx.com/>

From: Xep-support [mailto:xep-support-bounces@renderx.com] On Behalf Of Darren Munt
Sent: Sunday, April 09, 2017 6:35 PM
To: xep-support@renderx.com<mailto:xep-support@renderx.com>
Subject: [xep-support] Hyphenation issue in table

I have some text that contains hyphenated words. With the hyphenate attribute set to 'false', words with hyphens will not break, resulting in the following:

[cid:image003.png@01D2B292.DF728780]

If I set it to true, then I get unnecessary hyphenation:

[cid:image004.png@01D2B292.DF728780]

Is there a mode where I can get it to break on a hyphen but not otherwise? I actually don't understand why it is breaking the word 'control' when there is space for it on the next line?

_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html

image001.png
image002.png
image003.png
image004.png
Received on Mon Apr 10 14:04:44 2017

This archive was generated by hypermail 2.1.8 : Mon Apr 10 2017 - 14:04:49 PDT