Process Unicode scalar values over 255 to HTML entities #32
Conversation
|
I note that this intercept doesn't cope with extended grapheme clusters. |
|
I'm not sure we should escape these characters. https://www.w3.org/International/techniques/authoring-html.en?open=charset#charset Swift now uses UTF8 for characters within strings. HTML4 and HTML5 force Unicode of some type. And this tool is intended for applications in these new better defined domains. It is nicer for users working in languages that use these higher codes to be able to read the result and it should be left intact as UTF8. |
|
Further statement in the CommonMark spec
So Ink is conforming if it restricts the encoding to UTF8, and I see no current need to cover more encodings. |
|
Are you arguing that the line in the Ink
|
|
Yes it works if placed in proper HTML doc <!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8"></head><body>Do an inspect on the readme in Safari as rendered by Github and you will see the en-dash etc in native UTF8 Put the header fragment in front of the ink output and it will render fine in Safari. |
|
I agree that this is unnecessary, since the generated HTML renders properly when wrapped as steve-h mentions. |
|
I agree with @steve-h and @john-mueller - will close this one. Thanks anyway @gavineadie. |
Characters which are not in the single byte Unicode range are not rendered properly in the output generated by Ink. Characters like em dash (used in the Ink
README.mdfile) are passed through unchanged to the output HTML. There may be browser settings to cope with such extended graphemes but Safari, by default, does not.This code intercepts such characters and converts them to HTML entities so an em dash, for example, is converted to
—. I'm far from certain that I put that intercept in an optimal place, and is a pretty brute-force approach, but I'm sure discussion here will improve that.Note the correct rendering of a line from the Ink README: