-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Flatland example has a line that wraps badly #22
Comments
Playing with typeset on Windows 10/Firefox, I noticed the same bad break. Also notice that the continuation line "ed traveller..." is extremely tight. As the previous (short) line is already fairly loose, I think you could probably fit the entire "absent-minded" on that line, which would save a line and help the extremely tight following line loosen up. It might look even better to split "inconsiderate" and put "in-" on the loose line before. Then there would be plenty of room to move "minded" up a line, and the following line (without "ed") would be loosened. To get the desired indentation and space around the figure, you might have to extend the list of short line lengths. Other than that one thing, it looks pretty decent. I wonder if this example used Knuth-Liang hyphenation? I don't think it's supposed to word split at the last 2 letters (3 is the minimum). My purpose in looking at typeset is that I have just taken over the Perl port of it from Simon Cozens (see PhilterPaper/text-knuthplass, and Text::KnuthPlass on CPAN). In some examples I added, I see some poor break behavior, such as three lines in a row with split (hyphenated) words, including the penultimate line. My understanding of Knuth-Plass is that there should be large penalties for hyphenating two or more lines in a row, as well as for the next-to-last line. I need to go through and see if there were any bug fixes or enhancements missed by Simon leading up to the 2011-03-17 release of his port, as well as work that Bram has done since. Further discussion or suggestions are welcome here or on PhilterPaper/text-knuthplass issues. The same bad line wrap shows up in the frobnitzem/typeset fork. |
A slight possibility is that insufficient demerits are applied at the hard hyphen break (see #27). It might be interesting to revisit this issue once the demerits value is increased from 100 to something approaching 3000 (better yet, configurable). |
I changed every '100' to '3000' (except percentage calculations) in flatland/index.html and src/*.js, and it appeared to have no effect (at least, it didn't clear up this problem). Either I missed something or this wasn't the cause. |
I took another look at this, after changing the hyphenation penalty back to 100 (from 3000). It appears that the hyphenation may have been getting messed up by compound words such as absent-minded, so I added code to lib/hypher.js (src/hypher.js for frobnitzem/typeset) to handle hyphenated words like that:
Yeah, it's an ugly hack, but I detest Javascript because the diagnostics and error messages are literally non-existent. If someone would like to improve it, be my guest. It appears that the hypenateText() function above it is not called at all, which is a shame, as it appears to contain code intended to properly handle compound words! Also, take heed of the note about just the ASCII hyphen (U+002D) being supported -- a more general case would handle /, :, etc. -- maybe any punctuation sequence as a joiner. Also watch out for accented letters and non-breaking punctuation, and handle It looks like the hyphenation code is really doing a bad job. I saw absent-minded broken up as ab.sen.t-.mind.ed, magazines as ma.ga.zi.nes, and pentagonal as pen.tag.on.al. There are probably more that I overlooked. I don't know if Bram isn't quite using the Knuth-Liang algorithm, or if there's a problem with the patterns, but you should be careful if using this code for serious work (where bad word-breaking would make you look bad). Finally, the code works (more or less) with the minimum suffix (minimum tail of the word) set at 2 letters. As English prefers a minimum of 3, I tried that (lib/en-us.js, src/pattern.js in frobnitzem/typeset), but then this one paragraph (narrowed for Figure 2) showed only three lines and skipped 10 blank ones, resuming (no text lost) after the figure. The frobnitzem/typeset Flatland example behaves the same way -- both push 13 short line lengths onto the Line Lengths list, but for some reason nothing shows up for 10 lines! Unfortunately, none of this work managed to fix the original problem. At this point I'm going to take a break, and may look at it later. Much later. |
This thing was gnawing at me, as I want to check my Perl code against this package, so I took another look at it. I have concluded that the Knuth-Plass code appears to be working correctly, but something in the resulting HTML and CSS isn't behaving exactly as expected when the browser gets it. Here is the offending paragraph, as the "output" array before it's smooshed into an HTML string and replaces the old paragraph text:
It's doing a bunch of stuff which seems rather inefficient. I don't think that word-spacing requires integer numbers of px's, or why spaces are replaced with nbsp's. I'm also not sure what controls the line lengths. I have tried the following hand-coded replacement, using KP's line splitting, with good results:
Note that the line length is specified per line, so the browser has nothing to do with it. In both cases, I think the |
- Windows 10 - Hi-DPI (devicePixelRatio of 2) - Reproduced in Firefox Nightly, Edge and Chrome. - The font it selected is [Gentium Basic from Google Fonts](https://fonts.google.com/specimen/Gentium+Basic). It looks _ghastly_ at 16px, apparently. `` will get you the right font for attempting to reproduce the issue (make sure to adjust the body font-family if you have Minion Pro or Gentium available, of course).
If you are unable to reproduce it I’m quite willing to assist further in great detail. I have a project I believe this will work very well for and I want to help iron out any issues like this so people that use my software don’t run into this sort of thing ever.
The text was updated successfully, but these errors were encountered: