In line by line mode (either way) and side by side (which cascades to lbl) the external margin escape off the edge of the screen. I can not zoom out to fit the text.
iOS 18.6.2 iPhone 11 Pro
Is this a known issue, or would a deeper dive be useful?
Is it just that one sutta? I think we have seen that before when there are extremely long words. Some browsers won’t break them and it causes the view area to extend past the screen.
No, but it’s not the same in every sutta.
MN21 and MN23 are awful. MN22 has text right up to the edge of the screen but no over-run.
ETA screenshots
2 Likes
It is happening because of cīvarapiṇḍapātasenāsanagilānappaccayabhesajjaparikkhārahetu
I know this has been brought up before, I just don’t remember the resolution.
1 Like
In MN21, yes. Most likely.
and I’m guessing it’s aniccucchādanaparimaddanabhedanaviddhaṁsanadhammassa in MN23
4 Likes
I don’t know if it was that. I have posted about it before SuttaCentral: bug reports - #194 by Beaver and SuttaCentral: bug reports - #196 by Beaver
1 Like
Surely someone can fix this with a wee bit of JS based on the DPD compound splitter to drop in a discretionary hyphen. 
In AN 3.70 naccagītavāditavisūkadassanamālāgandhavilepanadhāraṇamaṇḍanavibhūsanaṭṭhānā automatically just continues on the next line without a hyphen (at least with just «line by line» activated for me).
I think both line by line and side by side worked for me on AN 3.70 on an earlier iOS, but now it zooms in with side by side.
1 Like
Another post there also mentioned it earlier and I happened to reproduce it on DN29.
And just reproduced (probably a second time as I seem to have liked posts on this thread before) MN21, MN22, MN23, DN16, AN3.70
Yes that appears to be correct. In DN29 it was “asammāsambuddhappavedite”, “dhammānudhammappaṭipanno”, and similar
For clarity & correct terminology, it isn’t “zooming”, the text is just not being bound by your device/viewport width, as Ven. Snowbird wrote above. Browsers have an unrelated zoom function, so it’s good to disambiguate as otherwise it can get pretty confusing to understand 
To get to the meat and potatoes, I seem to have fixed this as part of SuttaCentral: bug reports - #339 by agilgur5 by modifying overflow-wrap: break-word to overflow-wrap: anywhere. It fixed all of the instances above.
Fix in draft PR: fix(pali): use `overflow-wrap: anywhere` instead of `break-word` by agilgur5 · Pull Request #3689 · suttacentral/suttacentral · GitHub
One of the reasons I made it a draft is because I’m not sure why break-word isn’t working
The other is because it’s not nearly as nice as this solution. But it would be more complicated to do this in JS because you have to detect when a word is too long for the viewport and then figure out where to put a hyphen. Usually hyphenation is done by the browser itself. It might be worth adding some support upstream to browsers, or adding soft hyphens to giant Pali words
EDIT: Hmm, could combine those two options - insert soft hyphens via JS, then let the browser figure out where to use a hard hyphen 
4 Likes
I’m wondering if using <wbr /> or ­ would work though? It looks like it only actually breaks when the word reaches an overflow point. In these screenshots, just overflow:hidden. So any pali word that is a compound would be ­d or have a <wbr>
2 Likes
Yea I hadn’t thought about automatically inserting those with JS until like, ~10 minutes ago (after staring at the related MDN pages long enough…):
I’m not sure how performant that would be, but indeed I think that would work as a nicer solution.
Certainly not a one-liner though , so perhaps short-term merge my PR and long-term do automatic soft hyphens
2 Likes
I absolutely agree. It’s beyond my skillset.
For performance, we could limit the JS hyphenation to compounds over 20 characters (15 characters for headings). on a xs screen at 16px font-size we are getting around 30-40 characters per line.
EDIT
320px (Screen width) / 16px (font size) = 20 to get character limit. It’s not perfect but is concervative.
1 Like
Yes I was thinking if we only do the Pali and only longer words that would help a lot. But would still have to parse through each segment into words and get the length of each word. And then the handful of longer ones get compound split soft hyphens (which would be the most compute-intensive). Would probably want to benchmark that against DN16.
If it’s done as render-blocking, every ms adds up to user-visible latency, but if it’s deferred until after page load then small width screens see this bug until the splitter is done.
Could workaround that by having the messier overflow with no hyphens on initial load and then swap to the nicer one I suppose.
The most efficient would be to do it statically in CI, like as part of the nilakkhana transform. Essentially only run once on each text (unless there is a fix to the root).
Related is that, per the CSS, this also applies to Sanskrit (and Prakrit?) and probably other languages with compounds too. I assume for more contemporary languages though, browsers already have built-in hyphenators.
1 Like
I think Bhante or some one else has brought up the idea that in the palm leaf manuscript tradition pali words are broken where they run out of space on the page.
A js solution feels like unnecessary complication considering how rare the situation is.
2 Likes
Yes, but… this is fine for Thai/Sinhala/Burmese characters, because they split at a logical point due to those languages using syllabaries rather than individual characters.
Yes. I was thinking setting the paragraphs to overflow:hidden. The ­ can be added after loading. We could use an overflow listener to detect which suttas/paragraphs need splitting.
My argument would be to throw logic out the window. If we were talking about a print book I would feel differently.
It’s pure speculation, but I would guess that if those languages didn’t have the writing form that they do, they would still just split words any old where.
I’m just reluctant to add any more coding overhead than is essential. I’m also not sure with sandhi it’s even always possible to make a clean split between syllables. Very, very few people will be looking at the Pali as fluent readers. And if someone needs to know how to properly break down the word they can click on it and the DPD should split it just fine.
For me the only problem is that layout is impacted by these unbroken lines.
(I actually don’t care so much either way, despite all my babbling)
2 Likes
Thanks for not having an opinion 
I don’t want this to be too heavy either. I’m just throwing ideas around rn.
3 Likes
For some reason we are using lang="pli" and then nesting inside of that lang="la" (latin) inside. Does anyone have any ideas why we are doing this? It’s not a hyphen hack, that’s for sure! Neither of these languages have browser support for hyphenation.
Annoyingly (because we shouldn’t use it) lang="en" does a decent job of hyphenation, based on syllables. However, that’d be more wrong that calling our pali latin.
(for anyone reading the pali, I did just shove a long word in there).
As an aside, DN16 has 35 words longer than 25 characters. That’s the easy bit!
1 Like
Thanks to everyone for these ideas. I agree the issue must be addressed!
Given that the pali corpus is static, I wonder if it would be possible, rather than automatically detecting words over a certain length and figuring out how to insert ­, we made a list of long words and pre-inserted the tags by hand. Then when processing the texts for the web we can use the substituted forms (but keep the simple forms for search, etc.)
"cīvarapiṇḍapātasenāsanagilānappaccayabhesajjaparikkhārahetu":
"cīvara­piṇḍapāta­senāsana­gilānappaccaya­bhesajja­parikkhāra­hetu"
3 Likes
Yes, that is about where I had gotten to with my thinking. There’s no point in busting the same words over and over again.
Thanks to @chaz (Charith) I already had a nice clean version of all the sutta text with segment ids. I was able to generate some .tsv files based on 20, 25 and 30 character limits. The word is on the left and all segment ids containing that word are on the right 
If we go with 30 characters as our limit we only have 282 words to split. This could be done painstakingly manually. If we set the bar at 20 characters, there’s around 2500 words. I would hope that we can use the DPD spliter for this!
ETA: only sutta texts were used for this dataset
4 Likes