Post reply

Warning - while you were reading 2 new replies have been posted. You may wish to review your post.
Name:
Email:
Subject:
Tags:

Seperate each tag by a comma
Message icon:

Attach:
(Clear Attachment)
(more attachments)
Allowed file types: apk, doc, docx, gif, jpg, mpg, pdf, png, txt, zip, xls, 3gpp, mp2, mp3, wav, odt, ods, html, mp4, amr, apk, m4a, jpeg
Restrictions: 50 per post, maximum total size 150000KB, maximum individual size 150000KB
Note that any files attached will not be displayed until approved by a moderator.
Anti-spam: complete the task

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Johann
« on: March 07, 2020, 01:32:21 PM »

Quite better, the standard Sans-Serif, at least to read.

Nyom Cheav Villa once mentioned to be not able to work in/with the editor because it uses to jump (just because here in this topic) and Atma also came across that it is often hard to mark areas.
Posted by: Moritz
« on: March 07, 2020, 01:17:26 PM »

Moul Pali is only a "style/decor" font for Pali-words, not so known and possible had to read since old script. Like old German script after 2 Generations can no more be read. Atma used this sript for the cs-km pages and for the use of pali-words in dictionary as span. For editor general probably not good (my person still has a very hard to read, remember the different characters). It would also require much styling like line spaces 200% etc. since overlapping otherwise like Nyom has already seen.

I removed the CSS to use "Moul Pali" as standard script for Khmer in CodeMirror, so now the browser's/operating system's standard sans serif font would be used instead, which should be more readable.

Since Bhante mentioned, I also tested to use "KhmerOS Content" font for it. But I think it looks worse than the system's sans-serif default here in the editor, at least on my computer. Although I am not used to read Khmer fonts, still not really knowing the writing system, but to me the normal system font seems more readable, using more space.
I think most modern operating systems have readable Khmer fonts by default nowadays. So to add additional KhmerOS fonts might be obsolete at least for standard (not "decorative") text.

To compare how the difference looks here (on my computer), see the attached screenshots.

At http://sangham.net/test/fonts.html one can also see the difference between one's own browser's/system's standard sans-serif font and KhmerOS Content font. (So the first, "Standard Sans Serif", always depends on the system.)

Which one is more readable for you?



_/\_ _/\_ _/\_
Posted by: Johann
« on: April 28, 2019, 02:30:13 AM »

Sadhu, Sadhu.

Moul Pali is only a "style/decor" font for Pali-words, not so known and possible had to read since old script. Like old German script after 2 Generations can no more be read. Atma used this sript for the cs-km pages and for the use of pali-words in dictionary as span. For editor general probably not good (my person still has a very hard to read, remember the different characters). It would also require much styling like line spaces 200% etc. since overlapping otherwise like Nyom has already seen.



The fall back fonts on pc and android are different, but always easy to read. Most easy the android used. Fall backs of "Sans" but which is owned by google http://www.khmerfonts.info/fontinfo.php?font=2522

"Koh Santepheap" looks also fine and a nice name "Island of peace"...

PC (windows) uses Khmer OS System which is not so pleasing on small devices but possible best aside of Sans. As there is no font owned by the Sangha, fall back seems to be fine for general script and the tool to select wished scripts is more then comfortable in addition.

Mr Nathan ( sungkhum )might know much and more in regard of scripts, having been involved much in their development.

A screen-shot from mobil device (wsp are here dark-green). Position look perfect.





 Changing themes seems to cause different colors for wsp and it's endless and sisiphus-work to look for perfect style. If it looks ok for Nyom on pc and in standard theme, thats great. If one wishes other themes, that has already lot of ways and may be open for inspired gifts all the time.

For working direct in the editor, use dw as editor, the conditions are, aside of the spell-check, really great and comfortable.
Posted by: Moritz
« on: April 27, 2019, 10:42:07 PM »

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:
Code: [Select]
/*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.

_/\_

Posted by: Johann
« on: April 27, 2019, 11:11:53 AM »

Sadhu, Sadhu

Looks more/used easy for the eye, the color as well, either dark or white.

Maybe the other signs like the point of white space, the line break, can be made in the same color (then its easy to see them as a "kind").

If the zwps could be moved sight to the right, so that it comes between the characters without (like now) changing the width, and if it would be slight broader, then it might be even more easy to discriminate required and not so different as used.







Not sure if it is possible to use also a sign, like an arrow, for tabs.

Btw., by clicking Ctrl+F one can search within the text, also with regex, and all finds would be marked.
Posted by: Moritz
« on: April 27, 2019, 10:42:43 AM »

Just found out that there are even a lot of settings incl. the display of white spaces and line breaks. The layout and frontsize options are also very useful. Althought disable spell check, it's also possible to disable the editor to normal.



In regard of the "styling" of the zwsp Atma investigated a little the origin sphere of the editor and asked the developer, Mr. Marijn , so to possible find out how and where to simple edit.

Thanks to the hint I was able to make the zws a bit better looking (see screenshot). Now in light blue (for now not possible to turn on/off, will try to add option soon).
Other special characters (from the range of special characters defined by CodeMirror ) are still rendered as red dots.
If there are any suggestions for better colors, also for the space and line-break markers (shown when enabling the options "Show Whitespace" and "Display line numbers", respectively), I could change that as well.

_/\_

* Moritz The "line break" marker seems a bit buggy when using "Highlight current line" but not "Show line numbers". Then the marker will appear only at the end of the current line and stay there even when selecting a different line. Might be confusing. I will try to find out the reason. Maybe would be good to just combine "Highlight current line" and "Show line numbers" into one option, so that the error would never appear.
Posted by: Johann
« on: April 26, 2019, 08:24:08 PM »

Just found out that there are even a lot of settings incl. the display of white spaces and line breaks. The layout and frontsize options are also very useful. Althought disable spell check, it's also possible to disable the editor to normal.



In regard of the "styling" of the zwsp Atma investigated a little the origin sphere of the editor and asked the developer, Mr. Marijn , so to possible find out how and where to simple edit.

Posted by: Johann
« on: April 20, 2019, 01:10:58 PM »

Quote from: Upasaka Moritz
I don't understand the last half-sentence "giving ws, tabs or linebreaks not much sign".
The red zero-mark looks "brutal", yes, maybe possible to change that into a thin line instead of taking up a complete space. But normal white-spaces/tabs/linebreaks might be better shown more strongly visible? Or how was it meant?

Editors, at least if "more professional" usually show slight signs for certain line breaks, tabs, spaces (also word has this, this pi-like icon to switch on and off) and since syntax works much with them possible fine to have decent marks and zwsp is just one under them (red and brutal possible because it's a programmers enemy character, as far as it can be read and seldom used as important part of text). LibreO. uses decent signs. But it's all merely already comfort and for working it's great as it is as well. Surely the red point is very dominant and leaves one to oversee normal spaces.

Quote from: Upasaka Moritz
Good to hear that it appears to be useful so far.  :)

_/\_

Act-ually the quality of mind and it's object (joy with the object of ones scarifies), it's pureness counts and that is something only attained and gained by the doer and particularly shared by letting others known ones deeds. It's usual that such also is of much use in merely wordily manners as well, pleasing and easy nourishment. Mudita.
Posted by: Moritz
« on: April 20, 2019, 12:30:15 PM »

Sadhu, Sadhu

Didn't came across that this mod shows zwsp and great that the display of zwsp in compare view works. The possibility to write a zwsp might be great since certain keybords often lack of such.
Ah yes, the button. I will try ti add it again.
There was also the vkeyboard plugin mentioned before. I had tried it out a bit, but does not seem to work. Not updated for almost five years, it might be that some things have changed and become incompatible. But it is surely worth a look to see if one can find good methods there to make something like this work here again.

Not sure if a "way to toggle them on/off" is needed. When copy to word or odt, all seems fine. Sure, the display is somehow "brutal" and confusing, giving ws, tabs or linebreaks not much sign.
I don't understand the last half-sentence "giving ws, tabs or linebreaks not much sign".
The red zero-mark looks "brutal", yes, maybe possible to change that into a thin line instead of taking up a complete space. But normal white-spaces/tabs/linebreaks might be better shown more strongly visible? Or how was it meant?

Great work and much place to take ones goodness along, rejoice with it, and possible go on another time once again, delight in giving into something for good and liberating purpose. Mudita!

Good to hear that it appears to be useful so far.  :)

_/\_
Posted by: Johann
« on: April 20, 2019, 11:38:13 AM »

Sadhu, Sadhu

Didn't came across that this mod shows zwsp and great that the display of zwsp in compare view works. The possibility to write a zwsp might be great since certain keybords often lack of such.

Not sure if a "way to toggle them on/off" is needed. When copy to word or odt, all seems fine. Sure, the display is somehow "brutal" and confusing, giving ws, tabs or linebreaks not much sign.

Great work and much place to take ones goodness along, rejoice with it, and possible go on another time once again, delight in giving into something for good and liberating purpose. Mudita!
Posted by: Moritz
« on: April 20, 2019, 10:26:20 AM »

I think the best solution might be to simply use the already existing and previously mentioned CodeMirror plugin .

It has all the desired features for the editor, including display of ZWS, whitespace and line breaks, possible to turn on and off. I had previously not tested it and thought that ZWS display would not be included. But it is, and it all seems to be working perfectly.

ZWS is always displayed as red dots, taking up one space, and not possible to turn off. Perhaps I can find a way to toggle them on/off as well.


The only additional thing remaining from my plugin attempt would then be the display of ZWS on the revision comparison page.

For now, I have disabled the ZWS plugin and installed CodeMirror instead.

For the ZWS display in the comparison page to work properly (without inserting additional ZWS between tags etc.), it would be necessary to change something in the DokuWiki code directly, which is not possible with a plugin.
And the little bit of JavaScript and CSS can be included in conf/userall.css and conf/userscript.js, so no real plugin needed anymore for that.

Edit: Comparison page should be working now, only showing the ZWS where they really are. All necessary for that is in conf/userall.css (marked with comment), conf/userscript.js and line 1366 of inc/html.php, which was changed from
Code: [Select]
        echo html_insert_softbreaks($diffformatter->format($diff)); ?>
to
Code: [Select]
        echo html_insert_softbreaks(str_replace("\u{200B}", "\u{E000}", $diffformatter->format($diff))); ?>

_/\_
Posted by: Johann
« on: April 20, 2019, 06:31:30 AM »

Sadhu

If working further on a document outside of the editor one needs to replace the character then. Just a thought: what if the whitespace view (possible displaying linebreak, ws, tabs as well, similar like libre or word) can be turned on and off in the editor (where when off the normal character appear).

Amazing the effort here.
Posted by: Moritz
« on: April 19, 2019, 11:39:50 PM »

The previous html-value things are gone, copy and paste works so far with a special when copy from the editor window to libre-office (for example). Actually looking nice but maybe not intended:

No, not intended. But understandable. The unicode character E000 is used instead of ZWS to display the font. And that is also what is copied now, when copying from the textarea (since modifying the copying content did not work: removing line-breaks when trying to do so).

Since E000 belongs to the Unicode "Private use area" , its look is not defined by the unicode standard, but different fonts can define it as they want for their purposes.

I had expected that E000 and other "Private use area" unicode characters would not have a symbol defined in most fonts, displaying a generic placeholder sign (like an empty square, or a square with the code 'E000' written in it) instead.

So I thought it would just be displayed normally as just a placeholder square, something like this:
Code: [Select]
|E0|
|00|
(displayed as one small square symbol).

But it seems that for example LibreOffice will always try to find a font which has a character defined for this symbol, and use it. In this case there must be some font installed on the system where the character is defined and LibreOffice is automatically using that to display the E000 character. Otherwise it would be displayed as just a placeholder.

In any case, it is not possible for now to automatically replace the character with a real ZWS when copying. So one has to take care to replace it when editing in some other program. (But actually, pasting these characters back into the text area in ATI DokuWiki editor will not be a problem. It will then be saved as ZWS in DokuWiki.)

The comparison view seems to add "fictive" zwsp, but looks great as well so far.
Ah, now I think I know where this would come from. I have seen some function called "insertSoftBreaks" or similar, defined somewhere in the DokuWiki PHP code, and this is called when rendering the revision comparison page.
DokuWiki would insert ZWS characters on the comparison page, so that long code sections without space would be broken into different lines at some fitting positions, and not displayed as one huge line reaching out of the screen.
So I should try to make sure that the ZWS replacement happens before the insertSoftBreaks when displaying the comparison page. Should be possible to do so in the next days.

_/\_
Posted by: Johann
« on: April 19, 2019, 01:02:27 PM »

The previous html-value things are gone, copy and paste works so far with a special when copy from the editor window to libre-office (for example). Actually looking nice but maybe not intended:



The comparison view seems to add "fictive" zwsp, but looks great as well so far.



Posted by: Johann
« on: April 19, 2019, 12:52:13 PM »

Sadhu, Sadhu... may my person never hudles with comments and tests.  :) May Nyom spend a joyful Uposatha!

Atma will test on a little.