Thanks for the bug report; I edited the post to use LaTeX \vec{x}. (The combining arrow worked for me on Firefox 67.0.1 and was kind-of-ugly-but-definitely-renders on Chromium 74.0.3729.169, on Xubuntu 16.04)
It is probably a good idea to use LaTeX to encode such symbols.
I’ve been doing this thing where I prefer to use “plain” Unicode where possible (where, e.g., the subscript in “x₁” is 0x2081 SUBSCRIPT ONE) and only resort to “fancy” (and therefore suspicious) LaTeX when I really need it, but the reported Chrome-on-macOS behavior does slightly alter my perception of “really need it.”
I’ve been doing this thing where I prefer to use “plain” Unicode where possible
I entirely sympathize with this preference!
Unfortunately, proper rendering of Unicode depends on the availability of the requisite characters in the fallback fonts available in a user’s OS/client combination (which vary unpredictably). This means that the more exotic code points cannot be relied on to properly render with acceptable consistency.
Now, that having been said, and availability and proper rendering aside, I cannot endorse your use of such code points as U+2081 SUBSCRIPT ONE. Such typographic features as subscripts ought properly to be encoded via OpenType metadata[1], not via Unicode (and indeed I consider the existence of these code points to be a necessary evil at best, and possibly just a bad idea). In the case where OpenType metadata editing[2] is not available, the proper approach is either LaTeX, or “low-tech” approximations such as brackets.
Which, in turn, ought to be generated programmatically from, e.g., HTML markup (or even higher-level markup languages like Markdown or wiki markup), rather than inserted manually. This is because the output generation code must be able to decide whether to use OpenType metadata or whether to instead use lower-level approaches like the HTML+CSS layout system, etc., depending on the capabilities of the output medium in any given case.
Thanks for the bug report; I edited the post to use LaTeX
\vec{x}. (The combining arrow worked for me on Firefox 67.0.1 and was kind-of-ugly-but-definitely-renders on Chromium 74.0.3729.169, on Xubuntu 16.04)I’ve been doing this thing where I prefer to use “plain” Unicode where possible (where, e.g., the subscript in “x₁” is 0x2081 SUBSCRIPT ONE) and only resort to “fancy” (and therefore suspicious) LaTeX when I really need it, but the reported Chrome-on-macOS behavior does slightly alter my perception of “really need it.”
I entirely sympathize with this preference!
Unfortunately, proper rendering of Unicode depends on the availability of the requisite characters in the fallback fonts available in a user’s OS/client combination (which vary unpredictably). This means that the more exotic code points cannot be relied on to properly render with acceptable consistency.
Now, that having been said, and availability and proper rendering aside, I cannot endorse your use of such code points as U+2081 SUBSCRIPT ONE. Such typographic features as subscripts ought properly to be encoded via OpenType metadata[1], not via Unicode (and indeed I consider the existence of these code points to be a necessary evil at best, and possibly just a bad idea). In the case where OpenType metadata editing[2] is not available, the proper approach is either LaTeX, or “low-tech” approximations such as brackets.
Which, in turn, ought to be generated programmatically from, e.g., HTML markup (or even higher-level markup languages like Markdown or wiki markup), rather than inserted manually. This is because the output generation code must be able to decide whether to use OpenType metadata or whether to instead use lower-level approaches like the HTML+CSS layout system, etc., depending on the capabilities of the output medium in any given case.
That is, the editing of the requisite markup that will generate the proper OpenType metadata; see previous footnote.