(upstream bug/not solvable) RFE: viewer and print support of hyphens css

t0dd · 2020-05-30T02:46:52.370Z

Modern browsers now support the hyphens CSS property. Well, most of them.

https://caniuse.com/#feat=css-hyphens
https://css-tricks.com/almanac/properties/h/hyphenate/

I would love to be able to do this in certain documents and have it do the right thing:

<style>
p, li {
    hyphens: auto;
    text-align: justify;
    text-justify: auto;
} 
</style>

The justified text is beside the point. It’s the hypenation I would love to see supported. I suppose that is something that has to wait on the upstrream? What is the upstream and maybe I can file an RFE there?

Also, maybe have it be a “plugin”? It’s not really a plugin codewise, per se, but turning CSS on and off for the rendered markdown seems to be a “plugin” in some cases. Dunno. But being able to choose whether it is the default behavior may be nice.

This is definitely a “nice to have” for me and not a critical feature. I stage a lot of content in Joplin and then post it elsewhere. Some (most?) blog software and CMSs have hyphenation turned on by default.

Note also, there is a popular hyphenation.js code module. I know nothing about it other than I read it about it somewhere.

betternote · 2020-05-30T10:03:05.019Z

Hi,
unless I’m mistaken, the hyphenation works in Joplin.
I create a template containing

<head>
<style>
@import url("fullpathtoprofile/.config/joplin-desktop/for_tests.css")
</style>
</head>
<body>
</body>
</html>

I’m not familiar with CSS, and I read that you have to declare the language in order for the hyphenation to work.

t0dd · 2020-05-31T04:45:15.092Z

It doesn’t seem to, though I could be mistaken.

the “browser” (viewer or renderer in this case) has to support the feature. For example, Chrome still doesn’t fully support this feature, whereas Firefox has for some time (Firefox is usually a bit ahead of everyone else in maturity).
The language has to be properly set. This is usually done in the tag, which we can’t, as users, define. If I searched it out correctly, this is how the top of the viewer rendered html is declared:

<!DOCTYPE html>
<html>
<head id="joplin-container-root-head">
	<meta charset="UTF-8">

If I found the correct HTML from Joplin, that <html> tag is empty, and ideally it should not be. The <html ... > should have it’s lang attribute set. For me that would be "en" (see below). For others it would be something else. The challenge is that language could change note to note. Technically, it could change within the note, and the folks that need that sort of thing need to figure it out for themselves (see my <div ... > example further on. You’d likely want a default language (set in options), but then some mechanism to change it per note in Joplin. That would be the pedantic ideal. I’m not sure how far we’d want to take this, but the language setting should be set to something and right now it is set to nothing.

<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">

So. Two RFEs. Well, one is arguably a bug.

BUG: Your language setting in the Joplin Options should set the default lang attribute in the viewer’s html.
RFE: Make sure the hyphens css property works (it doesn’t, see below).

To test #2, I did this at the top of my markdown document …

<style type="text/css">
p, li {
  /* It almost looks like the Joplin viewer doesn't support any of these */
  word-wrap: break-word;
  overflow-wrap: break-word;
  hyphens: auto;
}
p {
  text-align: justify;
  text-justify: auto;
}
li, li p {
  text-align: left;
}
</style>
<div lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml" style="width: 6.5in;">

The content of my document starts here. Blah blah. Big long article.

</div>

And no hyphenation occurs.

betternote · 2020-05-31T09:10:31.789Z

Hi,
I admit my incompetence, I don’t know how to continue, because my tests on my system show that hyphenation works.
On the other hand, the export in html format does not contain the necessary tags to get the same result as with the viewer.
If I add the <html lang="en"> tag in the html file, the hyphenation works immediately in a browser.

t0dd · 2020-05-31T09:56:34.374Z

I have been experimenting.

Confirmed as best I could that Joplin does not have the lang="XX" set anywhere in the html that is rendered in the viewer. Therefore hyphenation can't work because it doesn't know what the heck language it is parsing.

That being said. You can set the language like I did with the <div lang="en" ... mentioned in the thread earlier. I.e., You can wrap all the content with your own manual tag (any tag by the way) and if it has the lang set correctly, it should hyphenate in the viewer. Alas, it does not. So . . .

Confirmed. The Joplin Viewer can't hyphenate properly or ignores the CSS or ignores the lang attribute. I suspect it merely doesn't support hyphenation in general.

My system is Linux. Fedora Linux 32. I don't know if that has anything to do with it (slightly different viewer tech?) but if you, @betternote, say the hyphenation is working in the Jopln Viewer on your system, maybe you have a different operating system? Weird that it would work for you though.

Note, I confirmed the <div lang="en" ... work around should work (i.e., my HTML and CSS is correct) by exporting a Joplin document to HTML and opening it in the browser. The text was lovingly hyphenated without any other manipulation needed.

It looks like the index.html that is used as the basis for the Joplin viewer is static and packed into the app.asar archive. I don't know that it would be easy to set the lang attribute for the html tag. Maybe by editing the XML DOM object on the fly? I will leave that to a develop to respond.

uxamanda · 2020-05-31T21:32:23.919Z

I added the following to my userstyle.css file:

p, li {
    word-wrap: break-word;
    overflow-wrap: break-word;
    hyphens: auto;
}

And see this as a result:
hyphen

I am on a Mac, so maybe it handles things differently, but just wanted to see if adding to userstyle.css (the css for the rendered markdown) might help.

t0dd · 2020-05-31T21:36:19.729Z

Interesting. Yeah, I did it within userstyle.css and within the <style> tags in the markdown itself (which is the same thing, effectively). I betcha the renderer is different on macOS.

@laurent Would that be the case? Different renderers depending on OS? Linux in my case and macOS in @uxamanda’s?

uxamanda · 2020-05-31T21:39:09.819Z

Looks like this might be a known limitation in Electron/Chromium for non-Mac OS. https://github.com/readium/readium-css/issues/31 Didn’t do a deep dive, but seems to be a similar problem.

t0dd · 2020-05-31T21:48:20.466Z

Ugh. Yeah. More specifically, I think this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=652964

They keep going around and around and around on it without solving it. Hey chrome guys! I know you are listening. Firefox solved this long long ago. Please solve this!

Grr.