Gentlemen,

Sometimes one can fall into a Unicode rabbit hole.

Here however I present a few desirable forms, for which we should consider 
if their font support is robust.

Using this link one can see a set of 
brackets. https://keyboard.cool/db/search?q=bracket
To me some share a likeness to existing markup symbols such as 

   - ⦃ tiddler title and transclusion ⦄
   - Space〖tiddler title and parenthesis〗with space
   - Perhaps even a block form 
   ︗
   Inside block
   ︘

What I did discover is the following 
<https://keyboard.cool/db/enclosed-alphanumeric-supplement/regional-indicator-symbol-letter-a>
 includes 
the letter symbols 🄐 - 🄩 and other sets. Some of which will show a color 
icon with the right fonts
[image: Snag_2a82c66a.png]
My thought is what if the glyphs available are from a set that an 
(optional) web font presents in an enhanced color form. Something one could 
toggle on/off? between plain and coloured.
In edit these would be bright and easy to see, but after wikification and 
when acting as customise symbols they are invisible. Of course unless you 
have misused them, like not used inline and not as the first non blank 
character, then they will be displayed and clear in the output. Thewy will 
also be visible as clear mark-up in the editor, again with the use of 
correct fonts.

Perhaps using such a range the customise feature can detect the range of 
characters, rather than only specified ones, at least for the leading line 
base glyphs. Ie a programmatic way for a larger number of glyphs to be made 
available.

Regards
Tones



On Wednesday, 25 November 2020 at 20:48:15 UTC+11 @TiddlyTweeter wrote:

> *"Braille" Has Advantage It is SINGLE Characters With Wide Font Support *
>
> PMario
> ⠒ braille⠶ ... 
> I did play around with "braille" a little bit and for me it is _not_ 
> visible enough in plain text. ... So I'm inclined to remove it for the 
> initial (beta) release. ...
>
> The INLINE "⠒ braille⠶ " pair retains merit (let us find a similar 
> alternative that is more "visible").
>
> WHY?
> Because for inline it is far better to have single characters than 
> doubled. "X text Y" is much better than "XY text YX" for readability and 
> typing.
>
> For these reasons I hope you will keep it for now!
>
> Best wishes
> TT
> On Monday, 23 November 2020 at 14:27:12 UTC+1 PMario wrote:
>
>> Sorry for the late reply. ... I Wasn't aware, that I can only see, if 
>> something is going on, if I change the group :/
>>
>> On Wednesday, November 18, 2020 at 11:48:23 PM UTC+1 TonyM wrote:
>> ...
>>
>>> 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?. 
>>>
>>
>> Hi folks, 
>> Interesting discussion. I did implement the different glyphs, for 
>> experimentation, so we can see how it works out. My conclusion atm is: That 
>> it creates way more problems, as it solves. .. Really! I don't want to 
>> explain, that users need a special font. .. It has to work out of the box. 
>>
>> At the moment we have:
>>
>>    - There are 4 "inline" elements
>>       - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
>>    - There are 6 "block" elements
>>       - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
>>    
>> I did play around with "braille" a little bit and for me it is _not_ 
>> visible enough in plain text. ... So I'm inclined to remove it for the 
>> initial (beta) release. ... 
>>
>> I do like "underscore" because it's easy to see in plain text, but it 
>> needs more internal code :/.
>>
>> "little" causes unicode problems. ... I'd like to remove it.
>>
>> So I may end up with "underscore" and "slash". They don't cause unicode 
>> problems and are present on every keyboard. 
>>
>> -----------
>>
>> I'm inclined to stick with the block elements for the initial release. 
>>
>> ------------
>>
>> My main point is, that I don't what to deal with the unicode support 
>> problems. The advanced usecase of the plugin is difficult enough to 
>> explain. 
>>
>> just some thoughts. 
>> -mario
>>
>>
>>

-- 
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/807519d1-3197-4a20-9aae-48f32aa73125n%40googlegroups.com.

Reply via email to