TT, I was thinking on this matter of unicode support, which could have consequences both for and in the use of custom wikitext. In many ways tiddlywiki "supports" Unicode, however for example no Unicode is usable in fieldnames, yet it is in titles, text and field values etc... However there is no reason we should not have a plugin and or a configuration option that supports Unicode. Not withstanding the need for local fonts, for example, windows covers most Unicode.
Now Unicode is a broad set and the large range of languages supported do not necessarily need to be part of a standard distribution, somehow we need to be both selective and try to be exhaustive or at least provide guidance. If I were a speaker of another language I may already be using fonts in my language and keyboards that support it. To Support Unicode it would be good if we had the tools to; - Detect if extended Unicode is in use in content during import - Determine if Unicode is present in a given wiki (higher Unicode character search?) - Provide information on what people will see when there is a missing font and how to remedy it - Perhaps a plugin that once active provides a subset of Unicode support, and if not so does not. basically designers or users will need to opt in to the more extensive Unicode, and on visiting a tiddlywiki we can see if the author has chosen to support extended Unicode. In may ways these activities are future issues being given strategic consideration today, along with the conscious decision to use "special characters" in the customise text solution. Why do I care? - As a designer or author access to extended character sets offers substantial potential. - TiddlyWiki is a master in knowledge and information storage and will benefit from robust support. - As Unicode use grows TiddlyWiki can be a leader in its use. - There are some nice innovations and self documentation features that can come from extended characters, in effect namespaces and more. So perhaps we now need to ask - How do we go about a degree of rationalisation - code pages English + Extended Symbols and utilities eg mathematical alphanumeric's - font recommendations - Multi-Platform support TT What do you perceive should be included?. Regards TonyM On Wednesday, 18 November 2020 at 22:18:33 UTC+11 @TiddlyTweeter wrote: > Ciao Tony & PMario > > TonyM wrote: >> >> >> I had not tested Android, although a big user. >> > > I think Android matters. Though personally I never use it for heavy edit, > its clear that lots of people do. > > It DOES raise an interesting issue of relevance to PMario too. > > I think it got clear through the 4 threads in this discussion that > UNIVERSAL support for ... > > -- Default Keyboards is likely IMPOSSIBLE > > -- Direct insertion via Keyboard ShortsCuts, and The Stamp Tool, is NOT > TOO DIFFICULT > > -- Unicode FONT SUPPORT requires research into CROSS-PLATFORM conditions. > > > For the DEFAULT plugin markup IDs it is BEST to have UNIVERSAL FONT > SUPPORT. > Otherwise we will create a huge "support problem". > > Therefore: in examining Candidate Glyphs the single most important issue > is good FONT support. > > I'm stating the obvious. But answering it is not trivial. > > Best wishes > TT > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikidev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/37c3b1b4-f15b-46d3-bc82-e5a642964aben%40googlegroups.com.
