Ah, I see. That must be because of using different fonts.
On my system, CodeMirror was using the default monospace font for the text area, while on the pictures shown above, a different (non-monospace) font is used (which is probably not installed on my system, and therefore the monospace font used instead).
I have inserted the ZWS marker as a simple '|' symbol, shifted slightly to the left, and overlayed, so not taking up any space of the actual text behind. The positioning would be different for different fonts. I chose -0.25rem (rem is a unit of text size in CSS, 1rem = current line height or something), which should be more or less correct for most monospace fonts.
I think between non-monospace fonts, there may be more differences, so it might not be possible to find a left shift value that works perfectly for every font.
For now, I have changed the CSS to use the borrowed "Moul Pali" font in the editor, and set the zws left shift to -0.125rem, which seems to fit well together. But I am not sure if Moul Pali is really a good font choice.
Since the Moul Pali font was actually not really used before, the Khmer texts seen on accesstoinsight.eu were always in some "default" fonts. So it seems there should not be a necessity to specifically include a font to support Khmer script. Khmer script seems to be included in most or many "standard" fonts nowadays, and browsers would automatically choose a font where the Khmer character is defined in most normal cases (if not explicitly setting a CSS rule to use _only_ one specific font, without default "fallback", which has no Khmer characters).
I also changed references to "Moul Pali" in
conf/userall.css, because they were all written wrong. (Need to be put into quotes, because of space in the name.) So "Moul Pali" was probably actually never used before.
Not sure where the following CSS rules are now visibly applied. Maybe Bhante might check if they are actually looking as intended:
/*pali khmer font span*/
@font-face { font-family: "Moul Pali"; src: url('Moul Pali.ttf'); }
.dokuwiki div.wrap_pali_km {
font-family:"Moul Pali", sans-serif;
font-size:80%;
}
.dokuwiki span.wrap_pali_km {
font-family:"Moul Pali", sans-serif;
font-size:80%;
}
/* ... */
.dokuwiki div.wrap_cs-km { font-family:"Moul Pali", sans-serif !important;
}
I set ", sans-serif" everywhere behind as a "fallback" (although Moul Pali is more of a Serif font) in all those cases where using "Moul Pali" as font. This means that if a character is not defined in Moul Pali, it will use the standard of the "sans-serif" family instead. This is how it generally works in CSS: if a symbol is not found, the browser will look in the next font of the list, and in general it would always fall back on one of the three "standard font families": monospace, serif or sans-serif. Normally, Moul Pali would fall back on "serif" for non-Khmer symbols, using whatever is the standard serif font on the system. But sans-serif seems generally better to read and fitting with the general DokuWiki style.
Maybe it would be better to not use "Moul Pali", because it is more like a Serif font, and some things can look a bit strange (see
screenshot ).
I think it might be best to use the standard font that is used on DokuWiki pages, which is "Arial, sans-serif" (i.e. using Windows "Arial" font if it is available, or otherwise whatever standard "sans-serif" is installed on the system).
For now, the editor font is set as "Moul Pali, sans-serif". But there is also a button now to choose a different font (need to enter a correct font name that is recognized on the system), so one can try out different fonts if one knows some font names (however it is probably best for compatibility on different systems to rely mostly on just the standard font-families "serif, sans-serif and monospace", if not having font files available to share).
The "insert ZWS" button is also included again:
[small]("insert ZWS" and "choose editor font" buttons)[/small]
Adding tab arrows is surely possible, but maybe difficult to implement well with non-monospace fonts and might need some time.
Ah, and I recognized the use of different "themes" in CodeMirror that one can choose. So I thought it is best to use one of the theme colors also for zero-whitespace (instead of a fixed color, that might not fit well with some themes).
The color themes of CodeMirror have a number of CSS classes for certain elements in the text, for example:
span.cm-keyword, span.cm-atom, span.cm-number, span.cm-def, span.cm-variable, span.cm-variable-2, ..., span.cm-operator, span.cm-property, span.cm-comment, ..., which have different colors for different themes and are used differently for whatever kind of "programming language" CodeMirror is set to use. (DokuWiki markup has its own CodeMirror definitions in the plugin).
For now, I chose the CSS class
cm-comment for the ZWS markers. I think the color is good for most themes. But feedback is welcome. One could try different things.