Techdoc showstopper: $ is a breaking character

This is the place to discuss Help & Manual 4 issues. Please don't post questions on any other versions here!

Moderators: Alexander Halser, Tim Green

User avatar
Sergey Tkachenko
Posts: 13
Joined: Sat Apr 23, 2005 6:21 pm
Contact:

Unread post by Sergey Tkachenko »

You can try in Internet Explorer:
The line
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa( aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
is broken before '(', regardless of space character after '('.
http://www.trichview.com
User avatar
Sergey Tkachenko
Posts: 13
Joined: Sat Apr 23, 2005 6:21 pm
Contact:

Unread post by Sergey Tkachenko »

I agree, ideally there should be two set of rules for breaking lines: higher priority breaks (like breaking white spaces) and lower priority breaks (such as breaking after ',' or before '('). The second set of rules should be applied when text between white spaces is too long (for example, more than the half of line).
May be it will be implemented in future, but not right now. But I am sure that complex rules give better result than simple breaking on spaces (especially when text area is narrow, for example in table cells).
http://www.trichview.com
User avatar
Alexander Halser
EC-Software Support
Posts: 4098
Joined: Mon Jun 24, 2002 7:24 pm
Location: Salzburg, Austria
Contact:

Unread post by Alexander Halser »

C'mon guys... Don't bash Sergey for a tiny bug in the word break function. I appreciate his participation in this thread very much!

We are going to fix this one, but I agree with Sergey (he is the author of the editor component that we use in Help & Manual): word breaks are a science in itself. There are more languages in this world than English and it really works differently in every language. Moreover, habits of using certain characters change over time. Just look at a text in Mandarin-Chinese 8)
Alexander Halser
Senior Software Architect, EC Software GmbH
User avatar
Dennis Delaney
Posts: 45
Joined: Sat Jan 24, 2004 2:03 pm

Unread post by Dennis Delaney »

I understand the problem with trying to find intelligent solutions for non-breaking characters, over-long words and so on. However, this is clearly an example of the clever solution being much, much worse than the problem it is trying to solve in the first place. The result is a broken editor that cannot break words correctly.

It would be much better to simply remove all these too too clever word-breaking algorithms completely, they only cause trouble 99.9999% of the time. They are not a solution, they ARE the problem. If you simple break on whitespace the editor will finally work correctly. The few cases where this causes problems are absolutely acceptable. The current situation where the algorithms are constantly causing incorrectly-formatted text is simply unacceptable, almost all the time.
Cheers,
Dennis
User avatar
Dean Whitlock
Posts: 577
Joined: Thu Sep 01, 2005 5:59 pm
Location: Thetford Center, Vermont USA
Contact:

Unread post by Dean Whitlock »

Martin,

Thanks for the laugh!

:lol:
Dean

PS. How is Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch pronounced? (And can you say it three times fast?)

Never mind - I found the pronunciation on this page:
http://www.anglesey-history.co.uk/
(And have decided that it's impossible to even say it one time, let alone fast.)
User avatar
Sergey Tkachenko
Posts: 13
Joined: Sat Apr 23, 2005 6:21 pm
Contact:

Unread post by Sergey Tkachenko »

Well, when complex line breaking was not implemented, the editor was blamed for the lack of it. Now it's vice versa.
Ok, I'll add an option to turn it off. But it will not be in this update, it will be added when I start working on improvements of line breaking as a whole. Probably this Summer.
But the problem with '$' will be solved soon.
http://www.trichview.com
Lyn Robinson
Posts: 2
Joined: Thu Nov 21, 2002 7:10 pm

Unread post by Lyn Robinson »

I am new to this discussion. My background includes working with the word processing software WordPerfect (WP) to prepare elegantly formatted user manuals. As I have configured WP, it does not line break within any continuous string of non-blank symbols. Nor does it break on any embedded no-break space (ALT+0160).

The only places that WP breaks paragraphs for me are at what the discussion thread calls "soft" spaces, at soft hyphens that I insert within isolated contiguous strings, and at another formatting special character that WP calls a "Hyphenation Soft Return" [HyphSRt].

If whatever appears after a [HyphSRt] fits entirely on the current line before a trailing soft space, nothing happens, the same as if I had inserted a soft hyphen instead. On the other hand, if the current line does not have enough room, whatever appears after the [HyphSRt] cleanly wraps to the next line, as if I had deliberately inserted a Hard Return (end-of-paragraph) there.

Unfortunately, H&M 4.5's editor does not behave this way, and I do not know how to alter its options so that it will. The soft hyphens work the same, but as some of the discussion thread recognizes, H&M's spell checker does not always ignore embedded soft hyhens.

Further, H&M's "soft line-break" always breaks. It may not trigger end-of-paragraph formatting/spacing, but I had not expected that anything labaled as "soft" would always break.

Instead, I would have preferred a soft break that works more like WP's [HyphSRt]. That is, similar to a soft hyphen but without the trailing hyphen at the end of the line.

I write HTML Help of use both under Windows Vista and under Windows XP. For a given HTML Help viewer window size, XP has more "room" in the viewer's right pane for text. This is because Vista's window frame takes up more space (thicker edges).

Consequently, if I want a topic to look reasonable, without a gigantic gap at the end of a line because some text string is too long to fit on a line in Vista's viewer, how do I format it? If I insert H&M's soft break so that the line looks OK under Vista, it frequently will have too big a gap at the end of the line under XP. This is because XP's greater effective line length sometimes would have allowed text appearing after a soft break to have fit comfortably on the line without the soft break. Yet H&M's soft break always breaks anyway, sometimes creating an undesirably long gap at the end of the line.

Have I misunderstood how to use H&M's soft breaks?
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Unread post by Tim Green »

Hi Lyn,

Breaks are one of the few weaknesses in the editor engine used in Help & Manual. We are working with the editor engine programmers to get this improved but it is a slow process. It was originally designed for electronic formats and needs to be improved for the finesses of print-based documentation as well.

As far as the spell checker is concerned we recommend always having live spell-check on as well as doing manual spell-checks -- this won't improve the performance in finding/ignoring soft hyphens but it will remind you as the author to keep an eye on things like this while you are working. This is how I work and I find that even if some errors aren't flagged by the red squigglies I tend to be more observant when spell check is on.

The "soft line break" is not labeled correctly. It is really a manual line break, the same as pressing Shift+Enter -- I'll see if I can get this changed, there is not really a soft line break capability in the editor. The soft hyphen characters are inserted for output purposes only, currently they may not be supported by either the editor or the spell checker.
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Sergey Tkachenko
Posts: 13
Joined: Sat Apr 23, 2005 6:21 pm
Contact:

Unread post by Sergey Tkachenko »

Probably "Zero Width Space" character (unicode 200B) can work as a "soft line break". This is an invisible space character.
Unfortunately, it really will cause problems with spellchecking, because programming interface for spellchecking is not Unicode. I plan to fix it in this year too.
http://www.trichview.com
Lyn Robinson
Posts: 2
Joined: Thu Nov 21, 2002 7:10 pm

Unread post by Lyn Robinson »

Thanks, Tim and Sergey. At least someone understands my dilemma. My current work-around when a soft hyphen simply will not serve my intent is to reword the offending paragraph. With judicious trial-and-error, I can always find something that fits well enough in both Viata and XP. Keep up the good work!
Post Reply