[twdev] Re: Custom markup (continued 4)

[PMario]

Hi Folks,

We continue at: https://github.com/wikilabs/plugins/discussions/56

have fun!
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/a1093ef9-aef8-47e6-b89e-20b9669a555bn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM

Thanks for the codes & ranges!

TT

On Thursday, 10 December 2020 at 23:50:33 UTC+1 TonyM wrote:

> TT,
>
> Here is a summary of the existing glyphs
> I established this with this site https://unicode-table.com/en/
>
> Latin-1 Supplement › Acute Accent
> ´ tick
> ´ Acute Accent
> U+00B4
>
>  Latin-1 Supplement › Degree Sign
> °
> ° Degree Sign
> U+00B0
>  
>
>
>  Small Form Variants › Small Left Parenthesis
> ﹙
> ﹙ Small Left Parenthesis
> U+FE59
>
>  Latin-1 Supplement › Pilcrow Sign
> ¶
> ¶ Pilcrow Sign
> paragraph sign
> U+00B6
>
> Braille Patterns › Braille Pattern Dots-25
> ⠒
> ⠒ Braille Pattern Dots-25
> U+2812
>  
>  
> Braille Patterns › Braille Pattern Dots-2356
> ⠶
> ⠶ Braille Pattern Dots-2356
> U+2836
>  
>  
>  Mathematical Operators › Almost Equal To
> ≈
> ≈ Almost Equal To
> asymptotic to
> U+2248
>
> Latin-1 Supplement › Right-Pointing Double Angle Quotation Mark
> »
> » Right-Pointing Double Angle Quotation Mark
> right guillemet, >>
> U+00BB
>
>
> Unicode Block Description Coverage
> U+0370–U+03FF Greek and Coptic 135 glyphs
> U+2070–U+209F Superscripts and Subscripts 48 glyphs
> U+2200–U+22FF Mathematical Operators 256 glyphs
> U+2300–U+23FF Miscellaneous Technical 256 glyphs
> U+27C0–U+27EF Miscellaneous Mathematical Symbols-A 48 glyphs
> U+2980–U+29FF Miscellaneous Mathematical Symbols-B 128 glyphs
> U+2A00–U+2AFF Supplemental Mathematical Operators 256 glyphs
> Glyph Variants (not all math) 1353 glyphs
>
>
> Regards
> Tony
> On Friday, 11 December 2020 at 06:02:52 UTC+11 @TiddlyTweeter wrote:
>
>> *Problems Of Working In The Dark*
>>
>> One of the biggest issues I have had is getting a CONSISTENT approach to 
>> both determining "Candidate Markup Glyphs" AND sharing them.
>>
>> I mean, before we go too far,  would it not be a good idea to identify by 
>> U+0023 numbers what we are talking about? Both for favourite pairings, or 
>> simple glyphs that strike you for markup?
>>
>> IF you give me the numbers I can begin to think easier how to extract 
>> them from a font!
>>
>> 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/de80d326-c36d-44a7-8a34-22c0a27bd77bn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

 TonyM wrote:

> Here is a summary of the existing glyphs
> I established this with this site https://unicode-table.com/en/
>

Just FYI I use the program BabelMap 
 on Win to investigate 
Unicode Font Support. Excellent program that has no registry dependencies. 
Has Plane and Block navigation, ability to tweak font stacks, and 
Bookmarking. Works well. Increased my practical understanding of Unicode 
font support more than anything else.

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/9a035a9d-a540-4a98-abe9-f1c1180fcc1cn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

Here is a summary of the existing glyphs
I established this with this site https://unicode-table.com/en/

Latin-1 Supplement › Acute Accent
´ tick
´ Acute Accent
U+00B4

 Latin-1 Supplement › Degree Sign
°
° Degree Sign
U+00B0
 


 Small Form Variants › Small Left Parenthesis
﹙
﹙ Small Left Parenthesis
U+FE59

 Latin-1 Supplement › Pilcrow Sign
¶
¶ Pilcrow Sign
paragraph sign
U+00B6

Braille Patterns › Braille Pattern Dots-25
⠒
⠒ Braille Pattern Dots-25
U+2812
 
 
Braille Patterns › Braille Pattern Dots-2356
⠶
⠶ Braille Pattern Dots-2356
U+2836
 
 
 Mathematical Operators › Almost Equal To
≈
≈ Almost Equal To
asymptotic to
U+2248

Latin-1 Supplement › Right-Pointing Double Angle Quotation Mark
»
» Right-Pointing Double Angle Quotation Mark
right guillemet, >>
U+00BB


Unicode Block Description Coverage
U+0370–U+03FF Greek and Coptic 135 glyphs
U+2070–U+209F Superscripts and Subscripts 48 glyphs
U+2200–U+22FF Mathematical Operators 256 glyphs
U+2300–U+23FF Miscellaneous Technical 256 glyphs
U+27C0–U+27EF Miscellaneous Mathematical Symbols-A 48 glyphs
U+2980–U+29FF Miscellaneous Mathematical Symbols-B 128 glyphs
U+2A00–U+2AFF Supplemental Mathematical Operators 256 glyphs
Glyph Variants (not all math) 1353 glyphs


Regards
Tony
On Friday, 11 December 2020 at 06:02:52 UTC+11 @TiddlyTweeter wrote:

> *Problems Of Working In The Dark*
>
> One of the biggest issues I have had is getting a CONSISTENT approach to 
> both determining "Candidate Markup Glyphs" AND sharing them.
>
> I mean, before we go too far,  would it not be a good idea to identify by 
> U+0023 numbers what we are talking about? Both for favourite pairings, or 
> simple glyphs that strike you for markup?
>
> IF you give me the numbers I can begin to think easier how to extract them 
> from a font!
>
> 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/d4078bbb-3f1d-481b-b51a-e4cb81f93c73n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Problems Of Working In The Dark*

One of the biggest issues I have had is getting a CONSISTENT approach to 
both determining "Candidate Markup Glyphs" AND sharing them.

I mean, before we go too far,  would it not be a good idea to identify by 
U+0023 numbers what we are talking about? Both for favourite pairings, or 
simple glyphs that strike you for markup?

IF you give me the numbers I can begin to think easier how to extract them 
from a font!

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/dbce183a-88e3-4d24-a718-adc6793ec14en%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Candidate Source Font(s)*

I been doing testing with the Google NOTO SANS font (sets) to see what the 
coverage is like... Up points ...

--- The Licensing is permissive and would allow extraction of glyphs to a 
new font.

--- The *Unicode coverage is very good *(the aim of Noto is to eventually 
cover the whole of Unicode)

--- The visual design is consistent across its component fonts.

Frankly, I'm not an expert in Font modification software, but, in principle 
this looks like a series of font sets that we might derive the glyphs we 
need from.

Thoughts
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/91896a57-2460-4ecb-9edb-7bd12042edffn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Note on KATEX plugin*

Tony's explore of Katex is useful! Tx! Studying it: it holds several fonts. 
WE don't need that complexity.

Rather, i think what we need is just *one *"Regular" font.

What impressed ME studying Katex is it totally clarifies HOW to embed a 
font in TW. Jeremy provides a bit of docs too which may prove helpful too.

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/a37ec45d-e189-46de-b342-95850648bafen%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Note On Custom Embedded Font*

Frankly I think that ultimately a custom (very small) font of ONLY markup 
glyphs is the BEST solution.

TonyM has shown that much of the time the normal font cascade on Windows 
will usually (but not determinately) work.
However there are additional issues even when it does. The main issue being 
that different fonts have *different design styles .*

I think it far better that ALL CustomMarkup Glyphs are visually consistent 
in design. Much better experience.

And I think it important we can GUARANTEE that the Glyphs are available in 
TW so it will work on all platforms without complications.

Regarding SIZE I will comment more later, but as far as I tested the CMFont 
would be no more than 10-30kb

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/eba1cbf0-0d2f-4e48-baea-3b7371f1ce90n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM & PMario

Sorry for my absence. I'm ill and not achieved yet what I was aiming it. 
That said, I have followed the discussion and done a bunch of background 
research which I will comment on next.

TT, x

-- 
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/f87cf316-9ef4-454b-8009-7498e48c14f7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Perhaps I should have emphasised obtain or  build our own WOFF file for a 
last resort font.  

In the Katex plugin the 
$:/plugins/tiddlywiki/katex/fonts/KaTeX_Math-Italic.woff 

 tiddler 
is only 30kb in size.

Regards
Tones 

On Wednesday, 9 December 2020 at 23:02:28 UTC+11 PMario wrote:

> On Wednesday, December 9, 2020 at 4:58:35 AM UTC+1 TonyM wrote:
>
> Many of the additional characters for maths is available inside the Katex 
>> plugin with the use of Woff files,  this plugin is less than 1mb in size.
>>
>
> If a font is about 1 MByte I'd add it to my PC, but in now way I would 
> want to add it to my wiki. I'm thinking about something in the 10th of 
> kiloBytes up to 100+kByte, that is acceptable. 
>
> -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/8b8ab6b9-b2a5-4b79-b12f-ae7a96c2439fn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Wednesday, December 9, 2020 at 4:58:35 AM UTC+1 TonyM wrote:

Many of the additional characters for maths is available inside the Katex 
> plugin with the use of Woff files,  this plugin is less than 1mb in size.
>

If a font is about 1 MByte I'd add it to my PC, but in now way I would want 
to add it to my wiki. I'm thinking about something in the 10th of kiloBytes 
up to 100+kByte, that is acceptable. 

-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/99a912a0-cc89-475b-88b8-cfb2af55a8d7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Observation,

Many of the additional characters for maths is available inside the Katex 
plugin with the use of Woff files,  this plugin is less than 1mb in size.

*The Web Open Font Format (WOFF) is a font 
 format for use in web 
 pages. WOFF files 
are OpenType  or TrueType 
 fonts, with format-specific 
compression applied and additional XML 
 metadata added. The two primary goals 
are to first distinguish font files intended for use as web fonts from 
fonts files intended for use in desktop applications via local 
installation, and second to reduce web font latency when fonts are 
transferred from a server to a client over a network connection. * 

If we could interrogate these fonts, identify the glyphs we use for 
customise in there and the we could make the katex plugin a co-requisit, or 
build our own WOFF file for a last resort font.

However my own experience is most devices can now show most "international" 
codepoints.

Tony
On Wednesday, 2 December 2020 at 16:28:41 UTC+11 TonyM wrote:

> Sorry Wrong link in my reply, part of my development.
>
> See https://www.unicode.org/Public/UCD/latest/ucd/BidiBrackets.txt for 
> open and close pairs.
>
> Tony
>
>
> On Wednesday, 2 December 2020 at 16:26:45 UTC+11 TonyM wrote:
>
>> *TT, et al*
>>
>> Yes lets start "* Unicode and Font Support in TW* " thread, however I 
>> was keen to make it easier for us to finalise on our glyphs to support 
>> closing that issue., thus relevant to this thread.
>>
>> This may be a possibility to build our own targeted font, but its looking 
>> to me like most platforms have access to glyphs for a wide range of Unicode 
>> already. 
>>
>> I also think making the fonts visible can also be an option. If we 
>> publish a wiki, and we rely on Unicode characters for customise,  and 
>> present output without those same characters visible, just used in code, 
>> all should work as expected. Only when editing a tiddler containing such 
>> characters they would not be able to read them, or tell them apart,  if 
>> they do not have the correct font. Ie functionality remains, visibility 
>> does not. The customise plugin can display these critical characters and 
>> note if they appear all the same, they need to update fonts available to 
>> view the glyphs. Or activate a sub-font with the select glyphs defined.
>>
>> From what I can see so far, a lot of platforms will have little trouble 
>> with the vast majority of Unicode Characters because of the sets commonly 
>> distributed to devices.
>>
>> *Jeremy,*
>> Interesting and Curious what you saw, I never did because I do not use 
>> rounded buttons. Many Unicode characters have different widths which must 
>> give rise to this.
>>
>> *PMario et al, Inline;*
>>
>> I just found this document which contains the matched braces available 
>> throughout Unicode 
>> https://www.unicode.org/Public/UCD/latest/ucd/Blocks.txt which may prove 
>> useful in the subsequent inline features.
>>
>> I continue to work on compiling information in a searchable tiddlywiki 
>> for managing "any" Unicode character or range.
>>
>> Tony
>> On Wednesday, 2 December 2020 at 04:42:53 UTC+11 @TiddlyTweeter wrote:
>>
>>> Ciao TonyM & PMario
>>>
>>> TonyM wrote:
>>>
 Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
 reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
  

>>>
>>> *TonyM*: That demo shows the issues arising over font support are 
>>> generic---Not Just for PMario Markup. I think we should pursue the broader 
>>> scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
>>> to start it? I have some solutions in mind. But they are refactory to this 
>>> thread.
>>>
>>> *PMario*: I think TonyM is *definitely heading in the right direction* 
>>> on trying to pin down font support issues for your Custom Markup by 
>>> illustration.
>>> I can see the beginning of a *solution*. One where reliable markup 
>>> glyphs could be always relied upon whatever platform you are on. It would 
>>> be *a very minimal font embedded in TW for JUST markup glyphs. It would 
>>> be kilobytes, not megabytes*. To get to the point of proof-of-concept I 
>>> need some days yet, but I'm getting close. Its just trudge over the Unicode 
>>> BMP to establish which fonts would provide the glyphs needed, cost free, to 
>>> make a good "TW-MarkupGlyphsFont".
>>>
>>> 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/990

[twdev] Re: Custom markup (continued 4)

[TonyM]

Sorry Wrong link in my reply, part of my development.

See https://www.unicode.org/Public/UCD/latest/ucd/BidiBrackets.txt for open 
and close pairs.

Tony


On Wednesday, 2 December 2020 at 16:26:45 UTC+11 TonyM wrote:

> *TT, et al*
>
> Yes lets start "* Unicode and Font Support in TW* " thread, however I was 
> keen to make it easier for us to finalise on our glyphs to support closing 
> that issue., thus relevant to this thread.
>
> This may be a possibility to build our own targeted font, but its looking 
> to me like most platforms have access to glyphs for a wide range of Unicode 
> already. 
>
> I also think making the fonts visible can also be an option. If we publish 
> a wiki, and we rely on Unicode characters for customise,  and present 
> output without those same characters visible, just used in code, all should 
> work as expected. Only when editing a tiddler containing such characters 
> they would not be able to read them, or tell them apart,  if they do not 
> have the correct font. Ie functionality remains, visibility does not. The 
> customise plugin can display these critical characters and note if they 
> appear all the same, they need to update fonts available to view the 
> glyphs. Or activate a sub-font with the select glyphs defined.
>
> From what I can see so far, a lot of platforms will have little trouble 
> with the vast majority of Unicode Characters because of the sets commonly 
> distributed to devices.
>
> *Jeremy,*
> Interesting and Curious what you saw, I never did because I do not use 
> rounded buttons. Many Unicode characters have different widths which must 
> give rise to this.
>
> *PMario et al, Inline;*
>
> I just found this document which contains the matched braces available 
> throughout Unicode 
> https://www.unicode.org/Public/UCD/latest/ucd/Blocks.txt which may prove 
> useful in the subsequent inline features.
>
> I continue to work on compiling information in a searchable tiddlywiki for 
> managing "any" Unicode character or range.
>
> Tony
> On Wednesday, 2 December 2020 at 04:42:53 UTC+11 @TiddlyTweeter wrote:
>
>> Ciao TonyM & PMario
>>
>> TonyM wrote:
>>
>>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>>>  
>>>
>>
>> *TonyM*: That demo shows the issues arising over font support are 
>> generic---Not Just for PMario Markup. I think we should pursue the broader 
>> scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
>> to start it? I have some solutions in mind. But they are refactory to this 
>> thread.
>>
>> *PMario*: I think TonyM is *definitely heading in the right direction* 
>> on trying to pin down font support issues for your Custom Markup by 
>> illustration.
>> I can see the beginning of a *solution*. One where reliable markup 
>> glyphs could be always relied upon whatever platform you are on. It would 
>> be *a very minimal font embedded in TW for JUST markup glyphs. It would 
>> be kilobytes, not megabytes*. To get to the point of proof-of-concept I 
>> need some days yet, but I'm getting close. Its just trudge over the Unicode 
>> BMP to establish which fonts would provide the glyphs needed, cost free, to 
>> make a good "TW-MarkupGlyphsFont".
>>
>> 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/254bd64c-2d67-4699-92f0-bfad14928793n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

*TT, et al*

Yes lets start "* Unicode and Font Support in TW* " thread, however I was 
keen to make it easier for us to finalise on our glyphs to support closing 
that issue., thus relevant to this thread.

This may be a possibility to build our own targeted font, but its looking 
to me like most platforms have access to glyphs for a wide range of Unicode 
already. 

I also think making the fonts visible can also be an option. If we publish 
a wiki, and we rely on Unicode characters for customise,  and present 
output without those same characters visible, just used in code, all should 
work as expected. Only when editing a tiddler containing such characters 
they would not be able to read them, or tell them apart,  if they do not 
have the correct font. Ie functionality remains, visibility does not. The 
customise plugin can display these critical characters and note if they 
appear all the same, they need to update fonts available to view the 
glyphs. Or activate a sub-font with the select glyphs defined.

>From what I can see so far, a lot of platforms will have little trouble 
with the vast majority of Unicode Characters because of the sets commonly 
distributed to devices.

*Jeremy,*
Interesting and Curious what you saw, I never did because I do not use 
rounded buttons. Many Unicode characters have different widths which must 
give rise to this.

*PMario et al, Inline;*

I just found this document which contains the matched braces available 
throughout Unicode https://www.unicode.org/Public/UCD/latest/ucd/Blocks.txt 
which may prove useful in the subsequent inline features.

I continue to work on compiling information in a searchable tiddlywiki for 
managing "any" Unicode character or range.

Tony
On Wednesday, 2 December 2020 at 04:42:53 UTC+11 @TiddlyTweeter wrote:

> Ciao TonyM & PMario
>
> TonyM wrote:
>
>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>>  
>>
>
> *TonyM*: That demo shows the issues arising over font support are 
> generic---Not Just for PMario Markup. I think we should pursue the broader 
> scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
> to start it? I have some solutions in mind. But they are refactory to this 
> thread.
>
> *PMario*: I think TonyM is *definitely heading in the right direction* on 
> trying to pin down font support issues for your Custom Markup by 
> illustration.
> I can see the beginning of a *solution*. One where reliable markup glyphs 
> could be always relied upon whatever platform you are on. It would be *a 
> very minimal font embedded in TW for JUST markup glyphs. It would be 
> kilobytes, not megabytes*. To get to the point of proof-of-concept I need 
> some days yet, but I'm getting close. Its just trudge over the Unicode BMP 
> to establish which fonts would provide the glyphs needed, cost free, to 
> make a good "TW-MarkupGlyphsFont".
>
> 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/bf0c0e64-bd67-455a-a6fe-2cf9d25fcb0bn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Tuesday, December 1, 2020 at 6:42:53 PM UTC+1 @TiddlyTweeter wrote:

*...* It would be *a very minimal font embedded in TW for JUST markup 
> glyphs. It would be kilobytes, not megabytes*. To get to the point of 
> proof-of-concept I need some days yet, but I'm getting close. Its just 
> trudge over the Unicode BMP to establish which fonts would provide the 
> glyphs needed, cost free, to make a good "TW-MarkupGlyphsFont".


If that would be available I'd be happy to test it. I'd install it directly 
on my PCs, to keep up with performance. ... But there are possibilities to 
add them with CSS too. So it should be simple to create a new plugin, that 
would provide this function. 

-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/89c69b8f-031d-432c-9714-84304a04fbefn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM & PMario

TonyM wrote:

> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable 
> Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>  
>

*TonyM*: That demo shows the issues arising over font support are 
generic---Not Just for PMario Markup. I think we should pursue the broader 
scope in a NEW thread. Maybe "Unicode and Font Support in TW". Do you want 
to start it? I have some solutions in mind. But they are refactory to this 
thread.

*PMario*: I think TonyM is *definitely heading in the right direction* on 
trying to pin down font support issues for your Custom Markup by 
illustration.
I can see the beginning of a *solution*. One where reliable markup glyphs 
could be always relied upon whatever platform you are on. It would be *a 
very minimal font embedded in TW for JUST markup glyphs. It would be 
kilobytes, not megabytes*. To get to the point of proof-of-concept I need 
some days yet, but I'm getting close. Its just trudge over the Unicode BMP 
to establish which fonts would provide the glyphs needed, cost free, to 
make a good "TW-MarkupGlyphsFont".

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/c592a5aa-d387-4a40-8b8d-2a6d1c2f172fn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

>
> On Thursday, November 26, 2020 at 11:17:50 AM UTC+1 @TiddlyTweeter wrote:
>
>> *BUG? v.0.8.1 -- Block Nesting Broken?*
>>
>
On Sunday, 29 November 2020 at 14:16:34 UTC+1 PMario wrote: 

> See _mode=block !!
>

RIGHT! I AM an idiot! Thanks for your patience. 

That admitted, I do think the inline/block setting importance needs 
(eventually) flagging more in docs.
I was away from the markup a week and forgot everything I learned. 
I kinda think grasping the sophistication of Custom Markup MIGHT be 
something of an issue.

Just thoughts
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/2508a4a1-10d3-45a4-ba23-3456a036e54bn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[coda coder]

https://wikilabs.github.io/editions/custom-markup/#Global%20Pragma%20Definitions

Perfect. Thanks, Mario.

On Sunday, November 29, 2020 at 7:55:01 AM UTC-6 PMario wrote:

> On Saturday, November 28, 2020 at 6:44:01 PM UTC+1 
> codacoder...@outlook.com wrote:
>
> *Scoping rules*
>> What is the scope of \somepragma? Is it possible to globally define them 
>> easily? I feel like I'm missing something obvious here. Wondering if 
>> $:/tags/Macro might do the job - it shouldn't but I'd understand if it did.
>>
>
> The scope is "per tiddler" .. but see: 
> https://wikilabs.github.io/editions/custom-markup/#Global%20Pragma%20Definitions:%5B%5BGlobal%20Pragma%20Definitions%5D%5D%20global-pragma-definition%20global-macro-definition
>
> AND
>
> Search for "global" at: https://wikilabs.github.io/editions/custom-markup 
>
> -m
>

-- 
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/3d0b220f-2dcd-4b60-9797-086cb9188632n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, November 28, 2020 at 6:44:01 PM UTC+1 codacoder...@outlook.com 
wrote:

*Scoping rules*
> What is the scope of \somepragma? Is it possible to globally define them 
> easily? I feel like I'm missing something obvious here. Wondering if 
> $:/tags/Macro might do the job - it shouldn't but I'd understand if it did.
>

The scope is "per tiddler" .. but see: 
https://wikilabs.github.io/editions/custom-markup/#Global%20Pragma%20Definitions:%5B%5BGlobal%20Pragma%20Definitions%5D%5D%20global-pragma-definition%20global-macro-definition

AND

Search for "global" at: https://wikilabs.github.io/editions/custom-markup 

-m

-- 
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/0b601810-f6b4-4126-9e92-6bcba6f21440n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Sunday, November 29, 2020 at 2:13:53 AM UTC+1 TonyM wrote:

> CodaCode
>
> Nice to see someone else buying into the vision.
>
 
+1
 

>
> *Scoping rules*
>> What is the scope of \somepragma? Is it possible to globally define them 
>> easily? I feel like I'm missing something obvious here. Wondering if 
>> $:/tags/Macro might do the job - it shouldn't but I'd understand if it did.
>>
>> Both local and global definition now exists, with local via either in 
> wikitext or by import pragma
>

Right. See the right sidebar: Contents !! .. There is a little bit of docs 
already. 


>
>> *Pragma definitions*
>> (@PMario) Like me, you were probably thankful when JavaScript started to 
>> support arrow functions - the brevity alone lent itself to a boost in 
>> productivity. Therefore I'm wondering why \customize can't be reduced:
>>
>>
> It could be perhaps, Mario will consider your suggestions; however the 
> definitions or customise pragma support such a broad and powerful range of 
> uses that brevity in the definition may be unwise. The whole function of 
> the new glyps and symbols it to create brevity by definitions. So perhaps 
> brevity in the definition, is a abstraction too far. 
>

I'd second that. The definitions should be as understandable as possible. 
 

>
>  I think the key place to play is 
> https://wikilabs.github.io/editions/custom-markup/, look for any tiddler 
> to see examples, this is not a curated site, just a practical one. Search 
> and play.
>

Right. Have a closer look at the "test-" prefixed tiddlers. I use them to 
test the different versions, to see if something is broken. ... The problem 
is, extending the code sometimes it's intended to be broken. Which makes it 
a bit difficult atm. 

The "content" tab in the right sidebar will hold the docs in the future. 

 The "special toolbar" and keyboard shortcuts are kind of broken atm. 
... I'll need to fix it. ... but atm core TiddlyWiki is super busy and I 
need the new actions functions for radio-buttons for this project !!!

-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/1c647d8a-0bde-4a9e-903e-c775a21a2c7en%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Thursday, November 26, 2020 at 11:17:50 AM UTC+1 @TiddlyTweeter wrote:

> *BUG? v.0.8.1 -- Block Nesting Broken?*
>

Try: 

\\ CUSTOM POETRY 
\\ -- container - 
\customize angle=POEM _element="div" _endString="/POEM" _mode=block 
_classes=".poem-c"
\\ -- components --- \\
\customize single=P-H _element="h3"
\customize pilcrow=P-B _element="div" _endString="/P-B" _mode=block


»POEM

  ›P-H JABBERWOCKY

  ¶P-B ´Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe:
All mimsy were the borogoves,
  And the mome raths outgrabe.
  /P-B

/POEM

See _mode=block !!

-- 
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/d93f8cf2-b879-436a-b681-18992bbd6ee6n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM

I looked more closely at the macro that constructs the Unicode charts you 
made from: 
https://anthonymuscio.github.io/PreReleaseGlyphs.html#New%20Tiddler

Man, that is brilliant!

Beyond its immediate use for our explore, it could be used well to 
illustrate in some docs how to solve a problem in TW elegantly for 
Intermediate level users. 

TT

On Saturday, 28 November 2020 at 11:56:27 UTC+1 @TiddlyTweeter wrote:

> Ciao TonyM
>
> TonyM wrote ...
>
>>
>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>>  
>>
>
> * Very good! *Hots off. Definite step in the right direction.
>
> Comments: *Load time is slow.* Is it GZipped? On Desktop its fine. On 
> Android smartphone is just never finished loading for me.
>
> For MARKUP glyph purposes it might be interesting to do a version more 
> delimited to "Text Markup Friendly" Unicode blocks?? A thought.
>
> 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/29af65bc-41e9-4201-93f8-a6842c398e94n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

codacoder...@outlook.com wrote:

>   Wow - I mean just WOW! I just spent I-don't-know-how-long reading all 
> this stuff - yes, ALL four threads 


My own sense is that what PMario initiated is very significant in 
potentiating/expanding WikiText to become a proper full-html/css 
methodology that is lightweight and powerful. By loosing the (often largely 
self-imposed) limits of Gruber (MarkDown inspired) styling we open up to 
actually using the power of CSS/HTML to make end-user writing much, much 
easier.

In particular, it will become much, much easier to quickly design efficient 
markup systemS without needing to hack Javascript parsers. Ones which just 
up-and-work. 

That is why I'm keen on doing what I can.

My 2 cents
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/e9239e83-7507-4558-b9e2-c6aec5bb6f29n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao. Nice to read you!

The "Joshua" v. "Josiah" conflate is an easy one to make since the 
"shortform" for both is "Jos."

Best wishes
Josiah

On Saturday, 28 November 2020 at 19:56:19 UTC+1 codacoder...@outlook.com 
wrote:

> On Saturday, November 28, 2020 at 11:44:01 AM UTC-6 coda coder wrote:
>
>>
>> Joshua - your guidance and background on unicode codepoints and the 
>> potential disconnect with font support is second to none. Excellent 
>> diligence!
>>
>> Face-palm - JOSIAH. Blame post-thanksgiving brainfog and a new son-in-law 
> called Joshua. :/
>
>

-- 
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/943f2454-4ff8-4723-befe-d57c0f101538n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

CodaCode

Nice to see someone else buying into the vision.

*Scoping rules*
> What is the scope of \somepragma? Is it possible to globally define them 
> easily? I feel like I'm missing something obvious here. Wondering if 
> $:/tags/Macro might do the job - it shouldn't but I'd understand if it did.
>
> Both local and global definition now exists, with local via either in 
wikitext or by import pragma


> *Pragma definitions*
> (@PMario) Like me, you were probably thankful when JavaScript started to 
> support arrow functions - the brevity alone lent itself to a boost in 
> productivity. Therefore I'm wondering why \customize can't be reduced:
>
>
It could be perhaps, Mario will consider your suggestions; however the 
definitions or customise pragma support such a broad and powerful range of 
uses that brevity in the definition may be unwise. The whole function of 
the new glyps and symbols it to create brevity by definitions. So perhaps 
brevity in the definition, is a abstraction too far. 

 I think the key place to play 
is https://wikilabs.github.io/editions/custom-markup/, look for any tiddler 
to see examples, this is not a curated site, just a practical one. Search 
and play.

You have swallowed the "red pill 
". More the discovery 
of infinite scope than unpleasant truths.

TonyM

-- 
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/86ea8dad-3d3d-4cea-bc69-d4ee3c00e07cn%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[coda coder]

On Saturday, November 28, 2020 at 11:44:01 AM UTC-6 coda coder wrote:

>
> Joshua - your guidance and background on unicode codepoints and the 
> potential disconnect with font support is second to none. Excellent 
> diligence!
>
> Face-palm - JOSIAH. Blame post-thanksgiving brainfog and a new son-in-law 
called Joshua. :/

-- 
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/a78ef3c5-80eb-487d-a113-2fd3ce7589d9n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[coda coder]

  Wow - I mean just WOW! I just spent I-don't-know-how-long reading all 
this stuff - yes, ALL four threads (I managed to resist hunting down any 
off shoots to the main forum but if there's anything over there I SHOULD 
read, please let me know!)

Joshua - your guidance and background on unicode codepoints and the 
potential disconnect with font support is second to none. Excellent 
diligence!

Tony - your meticulous testing and support of Mario is outstanding!

Mario. What can I say? Your parser knowledge and practical application is 
clearly well-grounded in TW code culture (a programming genre in its own 
right). HUGE congratulations for getting even this far.

Okay, praises over, now some questions - apologies in advance if I ask 
something you think clearly explained somewhere in the tome ("threads" 
seems like an understatement, so "tome" it is)...

*Scoping rules*
What is the scope of \somepragma? Is it possible to globally define them 
easily? I feel like I'm missing something obvious here. Wondering if 
$:/tags/Macro might do the job - it shouldn't but I'd understand if it did.


*Pragma definitions*
(@PMario) Like me, you were probably thankful when JavaScript started to 
support arrow functions - the brevity alone lent itself to a boost in 
productivity. Therefore I'm wondering why \customize can't be reduced:

Here is the code for your table example above:

\customize tick=table _element=table _endString="/endTable" _mode=block

Would/could something like this work?

\->table _mode=block
\->caption 

´table ´caption Some caption text
 ... stuff ...
´/table

I'm inferring that tick=table can be treated as redundant.

And, depending on your answer to my question about scope, use this for 
"local tiddler only" scope:

\->*table _mode=block

Thanks again for a fabulous read guys!

On Saturday, November 28, 2020 at 4:56:27 AM UTC-6 @TiddlyTweeter wrote:

> Ciao TonyM
>
> TonyM wrote ...
>
>>
>> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying 
>> reliable Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>>  
>>
>
> * Very good! *Hots off. Definite step in the right direction.
>
> Comments: *Load time is slow.* Is it GZipped? On Desktop its fine. On 
> Android smartphone is just never finished loading for me.
>
> For MARKUP glyph purposes it might be interesting to do a version more 
> delimited to "Text Markup Friendly" Unicode blocks?? A thought.
>
> 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/25eda647-66aa-4fc7-9c3f-7949958cc412n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM

TonyM wrote ...

>
> Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable 
> Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
>  
>

* Very good! *Hots off. Definite step in the right direction.

Comments: *Load time is slow.* Is it GZipped? On Desktop its fine. On 
Android smartphone is just never finished loading for me.

For MARKUP glyph purposes it might be interesting to do a version more 
delimited to "Text Markup Friendly" Unicode blocks?? A thought.

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/8b1da3d7-a3b7-4144-ad95-c7e73059db03n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM wrote:

> This article lists glyphs supported by an intersection of a set of fonts 
> .
>  
> Perhaps we could take this list and present it in a tiddler, in a large 
> font size and put it out to the user forum for people to test and report if 
> all the glyphs are visible. Perhaps also in an empty.html at a URL people 
> can just open an review on their various devices?


 The problem with that "intersection" (nice idea) is it does NOT really 
work to illuminate what is going on.

All that entering those glyphs would show is that somewhere in the "global 
font hierarchy" a character in a font (a character in some registered font 
somewhere) those glyphs exist.

It is unfortunate that there is little explicitness in most documentation 
that CHARACTER substitution is ADDITIVE to FONT CASCADE.
In CSS cascade you can MATCH on font but FAIL on CHARACTER. At that point 
another method of substitution arises that, as far as I can see, CSS 
doesn't fully control. The substitution "pretends" that the glyph exists in 
a font when actually it doesn't. It is an invisible process.

In reality, the "full substitution-stack", roughly speaking is: (1) CSS 
Font Cascade  > (2) Browser Cascade/Stack > (3) OS Font Stack. Not all OS, 
or browsers, handle this substitution logic the same way.
FYI (OS) Substitution rules read header data in Fonts to determine match to 
the nearest consanguineous font character in another similar looking font 
first. Etc. etc

This is a short way of saying: *What that would show is Machine Support, 
Not Specific CSS font support. *

*That is good!* But it isn't really providing the full clarity needed to 
pin down UNambigous reliability for markup glyphs.

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/096d1912-4f8b-48f5-95dd-256303725231n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

This article lists glyphs supported by an intersection of a set of fonts 
.
 
Perhaps we could take this list and present it in a tiddler, in a large 
font size and put it out to the user forum for people to test and report if 
all the glyphs are visible. Perhaps also in an empty.html at a URL people 
can just open an review on their various devices?

Here is my initial draft  Glyphs 5.1.23-prerelease — Identifying reliable 
Unicode Glyphs on TiddlyWiki Build Date (anthonymuscio.github.io) 
 
 
So far up looking at  to 65000 on Windows 10 (Chrome, FireFox and Edge) 
most are honoured however I have various local fonts that may be doing this.
Android also works mostly.

Regards
Tony
On Friday, 27 November 2020 at 20:21:22 UTC+11 @TiddlyTweeter wrote:

> Ciao TonyM
>
> TonyM wrote:
>
>> The thing I find frustrating is fonts seem not to document the "code 
>> pages" they include.  There must be Unicode rich ones available for linux 
>> and apple and other devices as there is for Windows. 
>>
>
> I agree. *Frustrating* is the word. It is one of those areas of OS 
> process that is simultaneously BRILLIANT and CONFUSING.
>
> It is *brilliant *in that modern glyph end-usage got so much easier. 
> Thanks to Unicode + improved Font File Architecture + Substitution 
> metadata. 
> It is *confusing* in that the OS+software mediated process of 
> substitution actually now makes it difficult to answer simple questions 
> about which fonts to use where---because the substitution process 
> transparently does it automatically. Unraveling that is really for an 
> expert in that specific field now.
>
> I did some tests in TW to see if I could get it to use a special Test Font 
> that Adobe provide which indexes ALL Unicode code points to a "blank." 
> Doing that you can, in theory, set a CSS cascade such that you effectively 
> switch-off substitution (i.e. cascade: Font, BlankFont). that make it quick 
> and easy to know which fonts truly hold a glyph.
> Unfortunately Windows 10 doesn't directly support the indexing method the 
> AdobeBlankVF font file uses. 
>
> I'm still playing around with the idea though.
>
> 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/55ffaa8d-652b-450a-8a62-d0369aea11e8n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM

TonyM wrote:

> The thing I find frustrating is fonts seem not to document the "code 
> pages" they include.  There must be Unicode rich ones available for linux 
> and apple and other devices as there is for Windows. 
>

I agree. *Frustrating* is the word. It is one of those areas of OS process 
that is simultaneously BRILLIANT and CONFUSING.

It is *brilliant *in that modern glyph end-usage got so much easier. Thanks 
to Unicode + improved Font File Architecture + Substitution metadata. 
It is *confusing* in that the OS+software mediated process of substitution 
actually now makes it difficult to answer simple questions about which 
fonts to use where---because the substitution process transparently does it 
automatically. Unraveling that is really for an expert in that specific 
field now.

I did some tests in TW to see if I could get it to use a special Test Font 
that Adobe provide which indexes ALL Unicode code points to a "blank." 
Doing that you can, in theory, set a CSS cascade such that you effectively 
switch-off substitution (i.e. cascade: Font, BlankFont). that make it quick 
and easy to know which fonts truly hold a glyph.
Unfortunately Windows 10 doesn't directly support the indexing method the 
AdobeBlankVF font file uses. 

I'm still playing around with the idea though.

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/cb4f0205-2377-406b-9374-e35d0654ea33n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM wrote:

> It would be interesting to look at a selective font, as a last resort, 
> that we could embed in tiddlywiki with only the symbols we need. I have 
> seen font builders around but it remains a bit of a dark art to me. Most 
> users such as myself have most of the Unicode covered (as I use Windows 10) 
> so a local font is likely to satisfy the requirements. I would be surprised 
> if any would have to revert to the last resort font if we choose the fonts 
> correctly (or check the existing ones)
>

Right. Last resort in an internal TW cascade. Lot of work BUT would be *a 
reliable way round Cross-Platform UN-certainty.*

Whilst I agree that Windows 10 "font stack" (i.e. substitution order by OS 
for fonts lacking in a TW defined CSS cascade) is very rich, it is still 
needing clarity on what is going on.

*Why? *Because different regional installs can make available different 
fonts in different W10 regions (Asian v. European probably being the 
largest mass issue). Frankly, I do NOT know, with certainty, how much of an 
issue this is in practice. The MS documentation is not that easy to 
understand. And the font substitution process is sophisticated.

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/f7287309-9f32-4690-a923-c51300de8444n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

It would be interesting to look at a selective font, as a last resort, that 
we could embed in tiddlywiki with only the symbols we need. I have seen 
font builders around but it remains a bit of a dark art to me. Most users 
such as myself have most of the Unicode covered (as I use Windows 10) so a 
local font is likely to satisfy the requirements. I would be surprised if 
any would have to revert to the last resort font if we choose the fonts 
correctly (or check the existing ones)

However I am not sure this is needed.

Font Family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, 
Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"
Code Font Family: "SFMono-Regular",Consolas,"Liberation 
Mono",Menlo,Courier,monospace


   - Then inside $:/themes/tiddlywiki/vanilla/base we see different font 
   family provided to different html elements. So in the development process 
   some recommendations have being followed or some serious analysis of fonts 
   generally available have being selected.
  - Perhaps we can find some updated recommendations that include the 
  additional character sets we need for all platforms.
  - In the above we may need to extend the Code Font Family.
   - If necessary we can just add via an additional stylesheet.
   - As I understand this we are listing fonts to use "if they exist 
   locally" and if they do not it reverts to the next best (using some details 
   of the fonts available)
   - When using customise we need to see our glyphs, and they do not appear 
   in the output, So a Tiddlywiki delivered to an audience that is not reading 
   the code it would not matter if no font exists for those Unicodes, the 
   customise should still work even without font glyphs available.

The thing I find frustrating is fonts seem not to document the "code pages" 
they include.  There must be Unicode rich ones available for linux and 
apple and other devices as there is for Windows. 

Tones

On Thursday, 26 November 2020 at 21:52:56 UTC+11 @TiddlyTweeter wrote:

> *Font-ish Thoughts ... *
>
> Ciao TonyM & PMario
>
> TonyM wrote:
>
>> What I did discover is the following 
>> 
>>  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. 
>>
>
> Right. Interesting ideas. If you look back you will see brief discussion 
> between me and PMario concerning *ways round the 'local machine' font 
> problem*.
>
> I think its worth commenting on some of the options ---
>
> 1 - *Use Web Fonts From Web. *I think PMario would not be too keen on 
> this as you'd need to online connect your wiki to a distant server and all 
> that involves. 
>
> 2 - *Use Web Fonts Once Downloaded. *Many free web fonts can be 
> downloaded. DOWNSIDE: adds *a lot *of complexity to set-up.
>
> 3 - *Embed Glyphs in a Custom Font that comes with the plugin*. This 
> might be good. ISSUES: What size would it be? Who would have knowledge how 
> to make it? And have the time? 
>
> 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/e6ad8f93-bfcf-4a90-b80a-d7fb0280aca7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Font-ish Thoughts ... *

Ciao TonyM & PMario

TonyM wrote:

> What I did discover is the following 
> 
>  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. 
>

Right. Interesting ideas. If you look back you will see brief discussion 
between me and PMario concerning *ways round the 'local machine' font 
problem*.

I think its worth commenting on some of the options ---

1 - *Use Web Fonts From Web. *I think PMario would not be too keen on this 
as you'd need to online connect your wiki to a distant server and all that 
involves. 

2 - *Use Web Fonts Once Downloaded. *Many free web fonts can be downloaded. 
DOWNSIDE: adds *a lot *of complexity to set-up.

3 - *Embed Glyphs in a Custom Font that comes with the plugin*. This might 
be good. ISSUES: What size would it be? Who would have knowledge how to 
make it? And have the time? 

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/21cab858-19e1-491c-a7c6-167f702bdef1n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*BUG? v.0.8.1 -- Block Nesting Broken?*

Ciao PMario

Below is example that fails to render nested elements. Code first. Render 
second.
Normal WikiText also fails within the scope of the "POEM" div. Failed part 
of example render in  RED.

Best wishes
TT


--- CODE -
\\ CUSTOM POETRY \\
\\ -- container - \\
\customize angle=POEM _element="div" _endString="/POEM" _classes=".poem-c"
\\ -- components --- \\
\customize single=P-H _element="h3"
\customize pilcrow=P-B _element="div" _endString="/P-B" 


»POEM

  ›P-H JABBERWOCKY

  ¶P-B ’Twas brillig, and the slithy toves
  Did gyre and gimble in the wabe:
All mimsy were the borogoves,
  And the mome raths outgrabe.
  /P-B

/POEM

--- RENDER --
 

 ›P-H JABBERWOCKY 

 ¶P-B ’Twas brillig, and the slithy toves 
 Did gyre and gimble in the wabe:
 All mimsy were the borogoves, 
 And the mome raths outgrabe. 
 /P-B 

 

-- 
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/5ebdf387-d0ba-4b3f-b7ad-4a437315a996n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

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 

 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.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*"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/8997d8bc-bc1e-42e5-b54c-f67820f0a433n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Goodbye ﹙ little﹚, Hello Font Supported Unicode*

PMario ...
"little" causes unicode problems. ... I'd like to remove it.  

I agree. (1) because of Unicode support; (2) because it is visually 
ambiguous.

However , worth noting,Tony's push for it can be addressed by other types 
of bracket IF the end user could define ID glyphs.

But for base release I think it is both not determined to be fully font 
supported and potentially confusing visually.

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/13512831-90f3-4fb3-94d9-4ba2d5ece475n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

PMario wrote
The advanced usecase of the plugin is difficult enough to explain.

Right. And the *ordinary* usecase needs time too.

FWIW, after a week away from Custom Markup I had to relearn it.

We really need a "crib sheet"--a one tiddler complete overview--I think, 
eventually.

I would be very happy to help on that if you agree on the need for it.

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/836ea61e-1317-4a85-b45b-aae8a8ee5a45n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM wrote:

> A quick look for "safe Unicode characters" gave me this 
> https://qntm.org/safe 
> I don't pretend to understand it fully but perhaps TT does.
>

Ciao TonyM. It is interesting and matches my understanding. Its actually 
reads more "scary" that we need. Most of the mentioned caveats would not 
arise in TW usage,
The reason it sounds somewhat complex is it is about Unicode in general (in 
any app). But WE only need be concerned with how it works in HTML & JS.

One big point he makes is about "Diacritical Marks" ("Combining 
Characters"). Actually the way they are used in HTML means you can use them 
NON-combining in a way you can't in most word processors. So that part of 
it take with a pinch of salt. Especially as those glyphs are common in 
European language fonts and could be useful.

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/57464e16-95a6-4f55-b5cd-d63a1b5792a0n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*The Problem With _Underscore_*

PMario...
I do like "underscore" because it's easy to see in plain text, but it needs 
more internal code :/.  

Hi Mario. In previous posts I have tried to show, with examples, why I 
think underscore is NOT a good idea.
Basically, IF it were not already used in TW for markup, I'd say it was 
brilliant. But is IS used already.

*I think using it in Custom Markup will be confusing.*

My two cents
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/5d74eb96-70d2-4974-b181-e5c2ce46dd68n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

PMario wrote:

>
> 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. 
>

Right. In any case the DEFAULT glyphs in the standard plugin I hope are 
finite in number and (pretty sure to be) in fonts on ALL machines.
Otherwise, as you say, it could become a support nightmare of missing fonts.
With at least some of them on KEYBOARD, so much the better too.

My interest in exploring Unicode is ...

-- IF you ever allowed a method to allow advanced users to define IDs. :-)

-- I think it could be VERY useful to be able to do so.

But note I also agree with TonyM that *there is more font support than we 
perhaps realise*.
The PROBLEM is to have a robust method to precisely determine what Unicode 
characters are UNIVERSALLY SUPPORTED.

My thoughts
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/24bee47a-9bd5-47e2-beb3-82b8e7394490n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I understand your concern in relationship to Unicode. But given TiddlyWiki 
has the content type;


And most systems have fonts for symbols, beyond the old ASCII sets I am 
sure we can find safe Unicode characters. TT may be the best to provide 
guidance here.

   - The dream would be keyboard enterable "glyphs" or mark-up. Way back 
   when this started I actually expected custom mark-up to be only triggered 
   by a leading period "." (first non blank character is "."), in effect an 
   escape character approach.
  - Of course now we have gone a long way past that and uncovered many 
  more possibilities.
   - A Unicode character is less likely to be found in imported text in the 
   exact way we use it as an "escape" character. 
   - As long as we can turn off and alter the escape character used, we can 
   adapt if the text contains our escape character
  - And since we need to rule in customised wiki text we are somewhat 
  safe here.
   
I am happy with the block approach first, it is already very powerful. Thus 
you could use the same principal, only if the escape character or glyph is 
the first non-space character (perhaps permit tabs etc..)

A quick look for "safe Unicode characters" gave me 
this https://qntm.org/safe 
I don't pretend to understand it fully but perhaps TT does.

Regards
Tony

On Tuesday, 24 November 2020 at 00:27:12 UTC+11 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/732c3bf5-0d9d-4309-882f-a28dcc81bcb7n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

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/7ac5056e-5afa-43ae-8154-86e1136b355an%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM

   - Determine if Unicode is present in a given wiki (higher Unicode 
   character search?)

Tech point.

To use regular expressions for higher Unicode (it would go through JS) in 
TW is simplest if one uses single Unicode code points in RANGES.
JS regex ranges for Unicode are recognised easily BUT there are TWO 
different methods which makes it confusing at first.

As far as I am aware only Tiddler Commander directly currently supports the 
consistently effective method (every character point is represented by only 
ONE hex number). This behavior is initiated via a regex flag (/u). 

Best wishes
TT

On Wednesday, 18 November 2020 at 23:48:23 UTC+1 TonyM wrote:

> 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/59fed92d-d46d-4675-8afe-170594df80f3n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

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.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

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/4039680e-9810-42b9-9763-2ca5536ebe8ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM wrote:
>
>
> determining one freely available that can ensure the lions share of 
> Unicode is available, this is what we must do.
>

Right!

I been looking at various methods for doing that.

I use BabelMap Portable, which is pretty good, to examine the font 
substitution process.

It is highly UNLIKELY with more esoteric glyphs that common fonts will hold 
them. 
Though many ARE available on local machines through substitution.

What we really need, IMO, is a TW that can be designed so that it itself 
presents selected Glyphs in various fonts (and ONLY those fonts).
The online tools I looked at for this (i.e. seeing precisely which Unicode 
characters render in which font) are not really adequate to our needs.
I'm trying to find a consistent & quick way to answer the issues of font 
support for TW in TW. 

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/5b29cb67-df74-4230-a105-a179300f876fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

I do understand your warnings on this, but I also know with the selection 
of an appropriate font, even pointing to one in a raw tiddler this should 
not be an issue, it is determining one freely available that can ensure the 
lions share of Unicode is available, this is what we must do. Ideally we 
find a font available and eventually ensure the empty version has it named.

I had not tested Android, although a big user.  Thanks for the feedback, 
not lets find the solution? I read how Microsoft has a few Unicode aware 
"default fonts".

Tony

On Saturday, 14 November 2020 at 20:55:18 UTC+11 @TiddlyTweeter wrote:

> Tony & PMario
>
> This illustrates issues in Font Support I mentoned earlier & in the main 
> group.
>
> In choosing Unicode solutions we do need to ensure they have font support 
> across OS.
>
> On Windows 10 I see (correct) ...
>
> [image: Screenshot 2020-11-14 103852.jpg]
> ... On my Android 8 the lead Unicode characters don't have font support  
> ...
>
> [image: Screenshot 2020-11-14 105020.jpg]
>
> This is why I refer to the "black art of Unicode". For reliable working 
> there needs to be quite a lot of checking.
>
> Best wishes
> TT
>
>
> On Wednesday, 11 November 2020 23:38:34 UTC+1, TonyM wrote:
>>
>> Further to this generic element solution;
>>
>> Eg;
>> ⮰td terminates end of line
>> ⭭tr terminates with /tr
>>
>> Only valid at the beginning of line it should be rare that a clash would 
>> occur.
>>
>> Tony
>>
>> On Thursday, 12 November 2020 09:18:24 UTC+11, TonyM wrote:
>>>
>>> Mario,
>>>
>>> I think I raised this previously, that perhaps one glyph should resort 
>>> to the element being equal to the symbol.
>>>
>>> Why?
>>>
>>> Because a large set of possibilities are opened up even without using 
>>> the customise pragma just some defaults.
>>>
>>> Eg;
>>> 'tr 
>>> would expect /tr and wrap the content in 
>>> 
>>> Without any further customisation.
>>>
>>> ie; the symbol is automatically adopted as the _element 
>>> Sure this can be customised however there are many cases where this, and 
>>> perhaps a .classname is more than enough
>>>
>>> Of course another glyph that does the same automatically terminates on 
>>> /n would also help eg;
>>> 'tr
>>> °td contents of table detail
>>> /tr
>>>
>>> °li contents of list item
>>> °li.bold bold contents of list item
>>>
>>> This is another way to help html/css savy users to make use of this 
>>> solution right out of the box with no customising.
>>>
>>> I could look from some appropriate glyphs rather than the above ' and °
>>>
>>> Regards
>>> Tones
>>>
>>>
>>> On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:

 Mario,

 That's why I favour customised 'tr and /tr  but then you have to be 
 familiar with html tables. 

 Regards
 Tony

 On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>
> Hi,
>
> I did a bit more docs for table formatting. So there are the same 
> formatting options as available with standard wikitext. 
> The only problem is, to find good "start" and "end" symbols, to make 
> the wikitext readable. 
>
> -m
>


-- 
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/e6fb5b16-4d8b-4f64-a469-b95131d591a4n%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Tony & PMario

This illustrates issues in Font Support I mentoned earlier & in the main 
group.

In choosing Unicode solutions we do need to ensure they have font support 
across OS.

On Windows 10 I see (correct) ...

[image: Screenshot 2020-11-14 103852.jpg]
... On my Android 8 the lead Unicode characters don't have font support  ...

[image: Screenshot 2020-11-14 105020.jpg]

This is why I refer to the "black art of Unicode". For reliable working 
there needs to be quite a lot of checking.

Best wishes
TT


On Wednesday, 11 November 2020 23:38:34 UTC+1, TonyM wrote:
>
> Further to this generic element solution;
>
> Eg;
> ⮰td terminates end of line
> ⭭tr terminates with /tr
>
> Only valid at the beginning of line it should be rare that a clash would 
> occur.
>
> Tony
>
> On Thursday, 12 November 2020 09:18:24 UTC+11, TonyM wrote:
>>
>> Mario,
>>
>> I think I raised this previously, that perhaps one glyph should resort to 
>> the element being equal to the symbol.
>>
>> Why?
>>
>> Because a large set of possibilities are opened up even without using the 
>> customise pragma just some defaults.
>>
>> Eg;
>> 'tr 
>> would expect /tr and wrap the content in 
>> 
>> Without any further customisation.
>>
>> ie; the symbol is automatically adopted as the _element 
>> Sure this can be customised however there are many cases where this, and 
>> perhaps a .classname is more than enough
>>
>> Of course another glyph that does the same automatically terminates on /n 
>> would also help eg;
>> 'tr
>> °td contents of table detail
>> /tr
>>
>> °li contents of list item
>> °li.bold bold contents of list item
>>
>> This is another way to help html/css savy users to make use of this 
>> solution right out of the box with no customising.
>>
>> I could look from some appropriate glyphs rather than the above ' and °
>>
>> Regards
>> Tones
>>
>>
>> On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>>>
>>> Mario,
>>>
>>> That's why I favour customised 'tr and /tr  but then you have to be 
>>> familiar with html tables. 
>>>
>>> Regards
>>> Tony
>>>
>>> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:

 Hi,

 I did a bit more docs for table formatting. So there are the same 
 formatting options as available with standard wikitext. 
 The only problem is, to find good "start" and "end" symbols, to make 
 the wikitext readable. 

 -m

>>>

-- 
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/164fa505-02c1-4577-94e8-4ad24cb40656o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Further to this generic element solution;

Eg;
⮰td terminates end of line
⭭tr terminates with /tr

Only valid at the beginning of line it should be rare that a clash would 
occur.

Tony

On Thursday, 12 November 2020 09:18:24 UTC+11, TonyM wrote:
>
> Mario,
>
> I think I raised this previously, that perhaps one glyph should resort to 
> the element being equal to the symbol.
>
> Why?
>
> Because a large set of possibilities are opened up even without using the 
> customise pragma just some defaults.
>
> Eg;
> 'tr 
> would expect /tr and wrap the content in 
> 
> Without any further customisation.
>
> ie; the symbol is automatically adopted as the _element 
> Sure this can be customised however there are many cases where this, and 
> perhaps a .classname is more than enough
>
> Of course another glyph that does the same automatically terminates on /n 
> would also help eg;
> 'tr
> °td contents of table detail
> /tr
>
> °li contents of list item
> °li.bold bold contents of list item
>
> This is another way to help html/css savy users to make use of this 
> solution right out of the box with no customising.
>
> I could look from some appropriate glyphs rather than the above ' and °
>
> Regards
> Tones
>
>
> On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>>
>> Mario,
>>
>> That's why I favour customised 'tr and /tr  but then you have to be 
>> familiar with html tables. 
>>
>> Regards
>> Tony
>>
>> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>>>
>>> Hi,
>>>
>>> I did a bit more docs for table formatting. So there are the same 
>>> formatting options as available with standard wikitext. 
>>> The only problem is, to find good "start" and "end" symbols, to make the 
>>> wikitext readable. 
>>>
>>> -m
>>>
>>

-- 
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/e3bb4243-c232-4be8-8fea-cf69624fc816o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I think I raised this previously, that perhaps one glyph should resort to 
the element being equal to the symbol.

Why?

Because a large set of possibilities are opened up even without using the 
customise pragma just some defaults.

Eg;
'tr 
would expect /tr and wrap the content in 

Without any further customisation.

ie; the symbol is automatically adopted as the _element 
Sure this can be customised however there are many cases where this, and 
perhaps a .classname is more than enough

Of course another glyph that does the same automatically terminates on /n 
would also help eg;
'tr
°td contents of table detail
/tr

°li contents of list item
°li.bold bold contents of list item

This is another way to help html/css savy users to make use of this 
solution right out of the box with no customising.

I could look from some appropriate glyphs rather than the above ' and °

Regards
Tones


On Saturday, 7 November 2020 09:39:43 UTC+11, TonyM wrote:
>
> Mario,
>
> That's why I favour customised 'tr and /tr  but then you have to be 
> familiar with html tables. 
>
> Regards
> Tony
>
> On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>>
>> Hi,
>>
>> I did a bit more docs for table formatting. So there are the same 
>> formatting options as available with standard wikitext. 
>> The only problem is, to find good "start" and "end" symbols, to make the 
>> wikitext readable. 
>>
>> -m
>>
>

-- 
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/4e820d69-5200-4e8b-9a93-0503c2a0390co%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao PMario

Sorry. I am getting lost in the wiki!

What Tiddlers do I need to look at to understand the additions/docs?

I'll comment then.

Best wishes
TT

On Friday, 6 November 2020 11:13:23 UTC+1, PMario wrote:
>
> Hi,
>
> I did a bit more docs for table formatting. So there are the same 
> formatting options as available with standard wikitext. 
> The only problem is, to find good "start" and "end" symbols, to make the 
> wikitext readable. 
>
> -m
>

-- 
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/60a3b004-44a7-4f7d-a325-b5072f76f466o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

That's why I favour customised 'tr and /tr  but then you have to be 
familiar with html tables. 

Regards
Tony

On Friday, 6 November 2020 21:13:23 UTC+11, PMario wrote:
>
> Hi,
>
> I did a bit more docs for table formatting. So there are the same 
> formatting options as available with standard wikitext. 
> The only problem is, to find good "start" and "end" symbols, to make the 
> wikitext readable. 
>
> -m
>

-- 
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/defb6d49-906e-4531-8ab1-526cad90655do%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi,

I did a bit more docs for table formatting. So there are the same 
formatting options as available with standard wikitext. 
The only problem is, to find good "start" and "end" symbols, to make the 
wikitext readable. 

-m

-- 
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/eb7de9b3-dac3-40f3-a101-aa702250d5ebo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Replacing the old nested sliders plugin from TWC

In this Discussion 
 a 
request mat be satisfied with custom wikitext.

Remember 
+++
content
+++
content2
===

===

Tony

On Tuesday, 3 November 2020 16:26:18 UTC+11, TonyM wrote:
>
> Gentlemen,
>
> I just discovered on Windows 10, Win+; opens a character dialogue in which 
> I can find »° and others.
>
> This means there is a simple though not too quick way to access many of 
> the glyphs we use.
>
> However I have being building tools in tiddlywiki for access to other 
> Unicode character sets. 
>
> Regards
> Tony
>
>

-- 
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/30414209-637b-431f-8714-2fd3b34bff70o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Gentlemen,

I just discovered on Windows 10, Win+; opens a character dialogue in which 
I can find »° and others.

This means there is a simple though not too quick way to access many of the 
glyphs we use.

However I have being building tools in tiddlywiki for access to other 
Unicode character sets. 

Regards
Tony

-- 
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/b6cc751f-b061-489a-9fb9-5b6ad0e32560o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao PMario & TonyM

I'm pretty sure that when Unicode started in 1991  
there was no idea that the characters 
would often get later "hi-jacked" for purposes never intended!

What we have in Unicode is a very vigorous standard that is then partially 
trashed FROM LACK OF ATTENTION TO THE NET AS AN EMERGENT SYMBOLIC LANGUAGE. 
Meaning, the origin of Unicode completely neglected that the Web was itself 
a language, deserving a dedicated plane. 

Its still like that.

IMO "we" basically, I mean ALL of us, are using it in a "bent" way a lot of 
the time.

Its got quite like the "Net" before the content/structure ideas emerged 
into "Web Standards" that cleaned things up.

Side thoughts
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/d239cd79-d974-46e2-8f5b-21765a252feco%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM

At some point I think we should go through the whole of Unicode Basic Plane 
and give a chart of USEFUL GLYPHS FOR MARKUP.
There are a lot of them, but they aren't infinite.

IMO understanding what is in Unicode AND supported in fonts on users 
machines by default is a primary issue.

Thoughts
TT

On Monday, 2 November 2020 09:52:33 UTC+1, TonyM wrote:
>
> Idea,
>
> It would be quite simple to find all uses of glyphname=symbolname 
> throughout a wiki to provide a Editor toolbar drop down list of existing 
> glyph/symbol definitions and on click insert them at the current location 
>  so the custom definitions are easier to lookup and 
> select. Self documenting if the symbols are chosen well.
>
> Tony
>
> On Sunday, 1 November 2020 11:44:36 UTC+11, TonyM wrote:
>>
>> TT,
>>
>> I did read your history, it's Quite interesting. And to some extent I 
>> defer to you, but in my return quote I pointed out the "modern" use of 
>> Pilcrow.
>>
>> It is interesting to know where the indented 1st line of a paragraph 
>> comes from, something I have never liked the aesthetics of, to be honest. 
>> You may be interested in this 
>> https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf
>>
>> What I do hope is in the end we can accommodate different mark-up needs, 
>> and in fact that is the value of this project. That is one reason I 
>> speculated if it were possible to have an end of line only mark-up symbol, 
>> not only because that is the way I would be inclined to use pilcrows, but 
>> to support other end of line annotations. I believe this may already be 
>> achieved with inline mark-up placed at the end of line. One persons end of 
>> line is another's beginning of line anyway, for example I can imagine ﹙¶
>> ﹚.
>>
>> I could see someone with the interest providing both the plugin and 
>> custom for anyone of these different systems. Not unlike they way a 
>> mathematician may extend tiddlywiki to their own mark-up language to 
>> represent complex maths, perhaps people may do this for old English, 
>> newspapers, PageMaker (One of the first professional printing applications 
>> and the use of postscript 
>> ).
>>  
>> The key being people can make tiddlywiki their own, in new ways, through 
>> the value of mark-up. Or as an example people preparing medieval style 
>> texts or writing about them.
>>
>> One example I am aware of is using custom mark-up to write HTML via 
>> shortcuts. Combined with tiddlywiki's automation I have always seen the 
>> potential for tiddlywiki to be configured to be a site designer and 
>> generator as well, this is where using html elements are helpful. One thing 
>> that excites me a lot is using an "arbitrary html tag" inside a custom 
>> mark-up. Basically it allows the writer to contain custom css and other 
>> "semantically appropriate" sections in the document. Add to this 
>> transclusion and macros an one could potentially generate a website by 
>> filling in some content settings and export (via zip) a whole multi-page 
>> site. Could this be a SquareSpace Wix killer? I have experimented with 
>> connecting to html and external javascript and there is a lot of potential 
>> there for more host interaction, I just do not have the skills yet.
>>
>> Yet another thought of late, is in response to filters, logical operators 
>> and the fact that filters handle sets. It seems to me the introduction of 
>> annotation for basic set manipulations would also be helpful. See in the 
>> pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression 
>> Equivalent 
>> named prefix
>>
>> Regards
>> Tony
>>
>>
>> On Sunday, 1 November 2020 03:57:52 UTC+11, @TiddlyTweeter wrote:
>>>
>>> TonyM wrote:

 ¶
 I would not bother with the use of pilcrow unless it was part of an end 
 of line form of glyph only. 

>>>
>>> Pilcrow has a complex history before printing, in printing & on the net. 
>>> They all diverge & overlap.
>>>
>>> Essentially the paragraph "mark" is a signal for a "longer pause" in 
>>> thought in all incarnations.
>>>
>>> I mention a bit of its history in some comments to PMario above.
>>>
>>> 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/f40d1b75-2425-4518-96a5-a24b42fb01a4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Looking at the SYNTAX for your Table Markup looks good!

I'd need to actually be able to use it to say more than that.

For instance, does it preserve the ALIGNMENT and CELL-MERGING tricks that 
current Wiki-Text has?

I personally think that Jeremy's WikiText for Tables is pretty amazing :-) 
So if you can go better--well--so much the better! :-)

Best wishes
TT

On Friday, 30 October 2020 14:55:25 UTC+1, PMario wrote:
>
> Hi folks,
>
> I'd like to discuss with you the table syntax as shown in
>
> \customize tick=table _element=table _endString="/endTable" _mode=block
> \customize tick=caption _element=caption
>
> \customize tick=! _element=th 
>
> \customize tick=cell _element=td _classes=".hl"
> \customize tick _use=cell
>
> \customize angle="===row" _element=tr _mode=block _endString="---"
> \customize angle=cmulti _element=td _classes=".hl" _mode=block 
> \customize angle=| _use=cmulti
>
> ´table ´caption Some caption text
> »===row
> ´! header 1
> ´! header 2
> ´! header 3
> ---
> »===row
> »| 1 text 
>
> »| 12 text «  and  » 
>
> »|
> * cell 13 text
> * line 2 
> * line 3 
> ---
> »===row
> »| 2 text 
>
> »| 22 text 
>
> »| 23 text 
>
> ---
> /endTable
>
> and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table
>
> Do you think it could be used as a default, shipped with the plugin. .. 
> The CSS for multiline and eg: bullet lists will need some adjustment .. 
>
> tick-cells are use for single line cells terminated by \n
> angle-cells are used for multi, block like cells terminated by \n\n
>
> »===row
>ends with 
> ---
>
> -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/ab0483df-97a5-47ad-a258-aaa87afa1645o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Idea,

It would be quite simple to find all uses of glyphname=symbolname 
throughout a wiki to provide a Editor toolbar drop down list of existing 
glyph/symbol definitions and on click insert them at the current location 
 so the custom definitions are easier to lookup and 
select. Self documenting if the symbols are chosen well.

Tony

On Sunday, 1 November 2020 11:44:36 UTC+11, TonyM wrote:
>
> TT,
>
> I did read your history, it's Quite interesting. And to some extent I 
> defer to you, but in my return quote I pointed out the "modern" use of 
> Pilcrow.
>
> It is interesting to know where the indented 1st line of a paragraph comes 
> from, something I have never liked the aesthetics of, to be honest. You may 
> be interested in this 
> https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf
>
> What I do hope is in the end we can accommodate different mark-up needs, 
> and in fact that is the value of this project. That is one reason I 
> speculated if it were possible to have an end of line only mark-up symbol, 
> not only because that is the way I would be inclined to use pilcrows, but 
> to support other end of line annotations. I believe this may already be 
> achieved with inline mark-up placed at the end of line. One persons end of 
> line is another's beginning of line anyway, for example I can imagine ﹙¶﹚.
>
> I could see someone with the interest providing both the plugin and custom 
> for anyone of these different systems. Not unlike they way a mathematician 
> may extend tiddlywiki to their own mark-up language to represent complex 
> maths, perhaps people may do this for old English, newspapers, PageMaker 
> (One of the first professional printing applications and the use of 
> postscript 
> ).
>  
> The key being people can make tiddlywiki their own, in new ways, through 
> the value of mark-up. Or as an example people preparing medieval style 
> texts or writing about them.
>
> One example I am aware of is using custom mark-up to write HTML via 
> shortcuts. Combined with tiddlywiki's automation I have always seen the 
> potential for tiddlywiki to be configured to be a site designer and 
> generator as well, this is where using html elements are helpful. One thing 
> that excites me a lot is using an "arbitrary html tag" inside a custom 
> mark-up. Basically it allows the writer to contain custom css and other 
> "semantically appropriate" sections in the document. Add to this 
> transclusion and macros an one could potentially generate a website by 
> filling in some content settings and export (via zip) a whole multi-page 
> site. Could this be a SquareSpace Wix killer? I have experimented with 
> connecting to html and external javascript and there is a lot of potential 
> there for more host interaction, I just do not have the skills yet.
>
> Yet another thought of late, is in response to filters, logical operators 
> and the fact that filters handle sets. It seems to me the introduction of 
> annotation for basic set manipulations would also be helpful. See in the 
> pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression Equivalent 
> named prefix
>
> Regards
> Tony
>
>
> On Sunday, 1 November 2020 03:57:52 UTC+11, @TiddlyTweeter wrote:
>>
>> TonyM wrote:
>>>
>>> ¶
>>> I would not bother with the use of pilcrow unless it was part of an end 
>>> of line form of glyph only. 
>>>
>>
>> Pilcrow has a complex history before printing, in printing & on the net. 
>> They all diverge & overlap.
>>
>> Essentially the paragraph "mark" is a signal for a "longer pause" in 
>> thought in all incarnations.
>>
>> I mention a bit of its history in some comments to PMario above.
>>
>> 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/90c6224a-82c8-491b-9254-34c6d83b7874o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

TT,

I did read your history, it's Quite interesting. And to some extent I defer 
to you, but in my return quote I pointed out the "modern" use of Pilcrow.

It is interesting to know where the indented 1st line of a paragraph comes 
from, something I have never liked the aesthetics of, to be honest. You may 
be interested in 
this https://unicode.org/L2/L2016/16235-two-medieval-chars.pdf

What I do hope is in the end we can accommodate different mark-up needs, 
and in fact that is the value of this project. That is one reason I 
speculated if it were possible to have an end of line only mark-up symbol, 
not only because that is the way I would be inclined to use pilcrows, but 
to support other end of line annotations. I believe this may already be 
achieved with inline mark-up placed at the end of line. One persons end of 
line is another's beginning of line anyway, for example I can imagine ﹙¶﹚.

I could see someone with the interest providing both the plugin and custom 
for anyone of these different systems. Not unlike they way a mathematician 
may extend tiddlywiki to their own mark-up language to represent complex 
maths, perhaps people may do this for old English, newspapers, PageMaker 
(One of the first professional printing applications and the use of 
postscript 
).
 
The key being people can make tiddlywiki their own, in new ways, through 
the value of mark-up. Or as an example people preparing medieval style 
texts or writing about them.

One example I am aware of is using custom mark-up to write HTML via 
shortcuts. Combined with tiddlywiki's automation I have always seen the 
potential for tiddlywiki to be configured to be a site designer and 
generator as well, this is where using html elements are helpful. One thing 
that excites me a lot is using an "arbitrary html tag" inside a custom 
mark-up. Basically it allows the writer to contain custom css and other 
"semantically appropriate" sections in the document. Add to this 
transclusion and macros an one could potentially generate a website by 
filling in some content settings and export (via zip) a whole multi-page 
site. Could this be a SquareSpace Wix killer? I have experimented with 
connecting to html and external javascript and there is a lot of potential 
there for more host interaction, I just do not have the skills yet.

Yet another thought of late, is in response to filters, logical operators 
and the fact that filters handle sets. It seems to me the introduction of 
annotation for basic set manipulations would also be helpful. See in the 
pre-release https://tiddlywiki.com/prerelease/#Filter%20Expression Equivalent 
named prefix

Regards
Tony


On Sunday, 1 November 2020 03:57:52 UTC+11, @TiddlyTweeter wrote:
>
> TonyM wrote:
>>
>> ¶
>> I would not bother with the use of pilcrow unless it was part of an end 
>> of line form of glyph only. 
>>
>
> Pilcrow has a complex history before printing, in printing & on the net. 
> They all diverge & overlap.
>
> Essentially the paragraph "mark" is a signal for a "longer pause" in 
> thought in all incarnations.
>
> I mention a bit of its history in some comments to PMario above.
>
> 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/2ae2294e-32f3-4543-940e-1da8c3579d3ao%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM wrote:
>
> ¶
> I would not bother with the use of pilcrow unless it was part of an end of 
> line form of glyph only. 
>

Pilcrow has a complex history before printing, in printing & on the net. 
They all diverge & overlap.

Essentially the paragraph "mark" is a signal for a "longer pause" in 
thought in all incarnations.

I mention a bit of its history in some comments to PMario above.

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/3efbe326-1823-4f3c-a21c-d1f7442790b0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM

Minor footnote clarifying an issue that comes up often in understanding 
Unicode font implementations.

There is masses to understand about Unicode!

My post mentioned that ...

None of the usual fonts European Language speakers would explicitly set in 
> TW settings have any of them (the doubled brackets) except Cambria Maths.


Why?

Because Asian languages use the same style of brackets NOT for Maths in 
normal writing. SO the WELL DESIGNED MATHS FONT includes, helpfully, 
duplicate signs that are for direct *non-math use* by Asian writers.

Best wishes
TT

On Saturday, 31 October 2020 09:42:25 UTC+1, @TiddlyTweeter wrote:
>
> *Markup Glyphs Should Be Visually Unique & Not Confused With Normal 
> Writing*
>
> TonyM wrote:
>>
>>
>> *A line with〖 This inline 〗and more
>>
>
> The use of glyphs CLEARLY DIFFERENT from normal text is *not just TT's 
> issue!*
>
> It's important not to have any default glyphs that look like any common, 
> conventional single glyph. ANY character that renders in font *like "(  
> ... )" is particularly bad *and should be avoided.
>
> Looking at your suggestion, the Unicode glyphs from *Basic Multilingual 
> Plane: CJK Symbols & Punctuation* look workable. ("CJK" means they are 
> Chinese, Japanese & Korean glyphs).
>
>
> 【】〘〙〚〛〖〗
>
> Their HTML entity numbers are ...
>
> 【】〘〙〚〛〖〗
>
> They have default font support on my Windows 10 tablet. But this is via 
> "font substitution" using shipped Asian fonts.
> None of the usual fonts European Language speakers would explicitly set in 
> TW settings have any of them except Cambria Maths.
> That is *not a problem *for us on Windows. I'm not sure if its a problem 
> for some Asian TW users. 
> ADDED: And I haven't confirmed if it works on Android yet.
>
> 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/0e2681e6-99f5-4773-b06f-180467a4f410o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao PMario
 

> @TiddlyTweeter wrote:
>
> The use case I am thinking of is allow me to simplyfy & share with others 
>> an approach to correct manuscripts. 
>> I work often using specialist software to proof edit articles & books for 
>> publishers.
>> This uses a specific method and its own system of glyphs (based on 
>> "printers' corrections").
>> The software involved is very complex and expensive.
>> I believe there is a way I could do this work in TW using your Custom 
>> Markup if I had a few special glyphs.
>>
>> I could explain it in detail if you wanted---but I don't want to overload 
>> you more than we have already :-)
>>
>
>
PMario ... 

> *It would be interesting to know*. .. Otherwise may implement changes, 
> that work against your usecase, because I don't know it. .. Which probably 
> has happend already as using the pilcrow as a "paragraph" marker. ... Which 
> makes it impossible to be used as an inline marker. ... 
>

Okay. Good. 

*Actually your pilcrow example is FINE!*

My issue is its hard to explain if I can't code it to make examples, but I 
can't code examples it until its done enough to code them. 

It's a "chicken-and-egg" problem. 
So let's leave that aside for now?

Right now, I reviewed my thoughts on this and I suspect it  is very few 
"base block glyphs" I'd like to be able to set. 
They are ALL "block" elements. "Inline" I can foresee about a dozen ;-). 
But they can be handled well IF in inline we can do ELEMENTS as we do for 
blocks already.

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/d2027246-87d8-4e38-8fb2-72d2b3af79eao%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

PMario wrote:
>
> @TiddlyTweeter wrote:
>
> P.S.: By the way the Pilcrow was originally used inline (often coloured 
>> red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the 
>> flow of a text. 
>> Vellum / parchment was very expensive so text is as condensed as 
>> possible. Paragraphs separated by lines evolved much later and was more to 
>> do with the development of printing and cheaper paper.
>>
>
> Yea, I've seen that. I did find this:
>
> Scribes would often leave space before paragraphs to allow rubricators 
>>  to draw the pilcrow. With 
>> the introduction of the printing press, space before paragraphs was still 
>> left for rubricators to draw by hand; however, rubricators could not draw 
>> fast enough for printers and often would leave the beginnings of the 
>> paragraphs as blank. This is how the indent before paragraphs was created.
>> [11]  Nevertheless, 
>> the pilcrow remains in use in modern time in the following ways: 
>>
>
> very interesting. ... I did ask myself for some time, where the indented 
> first line in paragraphs comes from.  Now I know :)
>

TBH my background has helped me a lot in writing for the net. 
I see the content/structure issue totally differently than most people.

That is what happens when you are fluent in Middle English :-).

When you stand back and look at it---"blocks" in HTML/CSS have innovated 
brilliantly over print media. 
BUT "inline" HTML/CSS seems badly scared to *loosen the hold of print! *
Most websites read like newspaper columns.

We are barely using our available freedoms in writing for the net.

Sure this is part OT. But not totally. 
I have to test more, but I'm getting clearer your Custom Markup method will 
let me PLAY with writing forms viably in the way I want to really.

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/bd8089de-9f41-402f-8b8a-049b35457b89o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 9:19:43 AM UTC+1, @TiddlyTweeter wrote:
>
> PMario wrote:
>
> Inline nesting seems to have a problem. 
>
>
> Right. I noticed that. Hope its solvable!
>

V0.8.1 should have fixed it. If not please report!
-m

-- 
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/02f1441b-e752-4d41-a900-20bdcbabe2c1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 11:05:06 AM UTC+1, @TiddlyTweeter wrote:

P.S.: By the way the Pilcrow was originally used inline (often coloured 
> red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the 
> flow of a text. 
> Vellum / parchment was very expensive so text is as condensed as possible. 
> Paragraphs separated by lines evolved much later and was more to do with 
> the development of printing and cheaper paper.
>

Yea, I've seen that. I did find this:

Scribes would often leave space before paragraphs to allow rubricators 
>  to draw the pilcrow. With the 
> introduction of the printing press, space before paragraphs was still left 
> for rubricators to draw by hand; however, rubricators could not draw fast 
> enough for printers and often would leave the beginnings of the paragraphs 
> as blank. This is how the indent before paragraphs was created.[11] 
>  Nevertheless, the 
> pilcrow remains in use in modern time in the following ways: 
>

very interesting. ... I did ask myself for some time, where the indented 
first line in paragraphs comes from.  Now I know :)

-m

-- 
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/a7c70fd3-ef03-4d1f-8af1-b15d0da408a1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 11:05:06 AM UTC+1, @TiddlyTweeter wrote:

The use case I am thinking of is allow me to simplyfy & share with others 
> an approach to correct manuscripts. 
> I work often using specialist software to proof edit articles & books for 
> publishers.
> This uses a specific method and its own system of glyphs (based on 
> "printers' corrections").
> The software involved is very complex and expensive.
> I believe there is a way I could do this work in TW using your Custom 
> Markup if I had a few special glyphs.
>
> I could explain it in detail if you wanted---but I don't want to overload 
> you more than we have already :-)
>

*It would be interesting to know*. .. Otherwise may implement changes, that 
work against your usecase, because I don't know it. .. Which probably has 
happend already as using the pilcrow as a "paragraph" marker. ... Which 
makes it impossible to be used as an inline marker. ... 

-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/cecd0bdb-d337-42be-bc0e-c33b838e2c18o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 10:01:42 AM UTC+1, @TiddlyTweeter wrote:

Can you please clarify what you mean here!
>
> Do you mean that are TWO different Unicode glyphs for Underscore being 
> used?
>

The default behaviour, should do the exact same thing as the existing 
__underline__ does. ... But it can be customized, if users want. 
At the moment, there is a little problem, since custom-markup needs 
__some text__ ... I'll need to fix that. 
-m

-- 
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/7d6e822f-ced1-449f-8333-2ab2e3fdba65o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao PMario

It would be possible to use pilcrows as "start" and "end" of a paragraph, 
> but I don't understand why. 
> TW Pargraphs end with \n\n by default
> So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
> personally it is confusing, since Libre Office and Word use: ¶  as a 
> paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
> paragraph. ... So the reverse pilcrow feels completely wrong at that 
> position.
>

The use case I am thinking of is allow me to simplyfy & share with others 
an approach to correct manuscripts. 
I work often using specialist software to proof edit articles & books for 
publishers.
This uses a specific method and its own system of glyphs (based on 
"printers' corrections").
The software involved is very complex and expensive.
I believe there is a way I could do this work in TW using your Custom 
Markup if I had a few special glyphs.

I could explain it in detail if you wanted---but I don't want to overload 
you more than we have already :-)

P.S.: By the way the Pilcrow was originally used inline (often coloured 
red) in Medieval manuscripts to indicate a ceasura / hiatus / pause in the 
flow of a text. 
Vellum / parchment was very expensive so text is as condensed as possible. 
Paragraphs separated by lines evolved much later and was more to do with 
the development of printing and cheaper paper.

Best wishes
TT

On Wednesday, 28 October 2020 15:53:12 UTC+1, PMario wrote:
>
> On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>>
>> *Regarding User Possibility To Set Markup Glyphs?*
>>
>> TonyM wrote:
>>>
>>>
>>> *Question - customised Glyphs, a glyph too far?*
>>>
>>>- As you can see the wide range of glyphs available that have 
>>>meaning or structure makes me wish to ask if we could allow the user to 
>>>nominate glyphs either single (line/para/blocks) or pairs for inline or 
>>>block. ie customise the customise glyphs.
>>>
>>>
>>  Ciao TonyM & PMario
>>
>> IF this were possible I WOULD use it.
>>
>
> ... need to think about it. But it would make configuration a hell lot 
> more complex.
>  
>
>> Why? Because the kinds of Markup I do would benefit from me being able to 
>> choose glyphs VISUALLY SUITED to the purpose.
>> For instance, for simple paragraphs ...
>>
>> ¶ Start of a paragraph,
>> more of the same pargraph endedon the next line.
>> ⁋ <--- End String
>>
>> I understand if its not possible. 
>>
>
> It would be possible to use pilcrows as "start" and "end" of a paragraph, 
> but I don't understand why. 
>
> TW Pargraphs end with \n\n by default
>
> So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
> personally it is confusing, since Libre Office and Word use: ¶  as a 
> paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
> paragraph. ... So the reverse pilcrow feels completely wrong at that 
> position.
>
> *I could implement:*
>
> ¶ some text \n\n
>
> Since it would be the right thing to do. see: Wikipedia Pilcrow 
> . It would be easy to explain, 
> with the link to Wikipedia. It will create a HTML P tag by default.
>
> If you want you can define an _endString. ... Default would be \n\n
>
> -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/1da32d83-e218-4b1c-8d84-ae02cbdf0955o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

PMario & TonyM

Can you please clarify what you mean here!

Do you mean that are TWO different Unicode glyphs for Underscore being used?

Best wishes
TT

On Saturday, 31 October 2020 09:14:29 UTC+1, PMario wrote:
>
> On Saturday, October 31, 2020 at 1:36:14 AM UTC+1, TonyM wrote:
>
> Just for clarification the double underscore (not underscore) is used, 
>> does this not clash with its existing use?, or is this intentional?
>>
>
> As default, it will do the same thing. So it shouldn't be a problem. But I 
> need to fix it. Atm it isn't 100% the same.
>  
>
>>
>> It is available on most keyboards.
>>
>
> yes 
> -m
>

-- 
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/b2a80e2b-0932-4556-8a32-8a619e7e93d6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

TonyM wrote:
>
>
> *A line with〖 This inline 〗and more
>

The use of glyphs CLEARLY DIFFERENT from normal text is not just TT's issue!

It's important not to have any default glyphs that look like any common, 
conventional single glyph. ANY character that renders in font like "(  ... 
)" is particularly bad and should be avoided.

Looking at your suggestion, the Unicode glyphs from *Basic Multilingual 
Plane: CJK Symbols & Punctuation* look workable. ("CJK" means they are 
Chinese, Japanese & Korean glyphs).


【】〘〙〚〛〖〗

Their HTML entity numbers are ...

【】〘〙〚〛〖〗

They have default font support on my Windows 10 tablet. But this is via 
"font substitution" using shipped Asian fonts.
None of the usual fonts European Language speakers would explicitly set in 
TW settings have any of them except Cambria Maths.
That is not a problem for us. I'm not sure if its a problem for some Asian 
TW users.

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/6cdbe216-5167-45dc-aa55-49180e368cc3o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

PMario wrote:

Inline nesting seems to have a problem. 


Right. I noticed that. Hope its solvable!

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/a5de16bd-ccbb-4268-97a0-1e94476c16e1o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 1:44:27 AM UTC+1, TonyM wrote:


> This would allow redefinition of mark-up already in a text perhaps even 
> making it behave like another mark-up language.
> and additions like
> \customise glyph="-" _element="li"
>
> - to accept bullets pasted from GitHub
>
>
I was thinking about that too. BUT the github bullet points work in a 
different  way. eg:

 - 
- 

and so on. I think I'll create a new plugin for them.

-m


-- 
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/2c1966bc-0781-4d67-9188-54bbde392384o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Saturday, October 31, 2020 at 1:36:14 AM UTC+1, TonyM wrote:

Just for clarification the double underscore (not underscore) is used, does 
> this not clash with its existing use?, or is this intentional?
>

As default, it will do the same thing. So it shouldn't be a problem. But I 
need to fix it. Atm it isn't 100% the same.
 

>
> It is available on most keyboards.
>

yes 
-m

-- 
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/81f63c41-220b-4e6a-8bc3-b28f0b7eeb78o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

Ciao TonyM

Quick query. 

When you suggest glyphs can you please also give the Unicode NUMBER!

In that way we can check where they have a chance of working (being in 
fonts) across platforms & setups.

Best wishes
TT

On Saturday, 31 October 2020 02:03:36 UTC+1, TonyM wrote:
>
> Do note I found these alternate small braces that may be better.
> ﹙₍ ₎﹚
>
> Regards
> Tony
>
> On Saturday, 31 October 2020 12:01:43 UTC+11, TonyM wrote:
>>
>> Mario,
>>
>> I would be keen to see these additional inline glyphs made available. 
>> They look like a fusion of [ ] and ( )
>>
>> It would be ideal for mark-up that involves links or buttons and where 
>> the content is considered a title.
>>
>> *A line with〖 This inline 〗and more
>>
>>
>>- They also look good when no customisation plugin is in use but does 
>>communicate, if it were, this would be treated differently. 
>>- I would for example use it like [[ ]] but to trigger a button to 
>>create the tiddler from a template
>>- Or 〖task This inline 〗to create from the task template
>>- Its the more visible version TT is asking for.
>>
>> However I do want you to retain ﹙ little﹚ for the same reason TT does 
>> not want them, they are similar but different to ( ) and less visible. 
>>
>>- TT can just "*not use them"* if he does not like them (I say with 
>>all due respect).
>>
>>
>> Tony
>>
>

-- 
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/568f4f4e-ac06-42cd-9249-7b0071eaf74fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Do note I found these alternate small braces that may be better.
﹙₍ ₎﹚

Regards
Tony

On Saturday, 31 October 2020 12:01:43 UTC+11, TonyM wrote:
>
> Mario,
>
> I would be keen to see these additional inline glyphs made available. They 
> look like a fusion of [ ] and ( )
>
> It would be ideal for mark-up that involves links or buttons and where the 
> content is considered a title.
>
> *A line with〖 This inline 〗and more
>
>
>- They also look good when no customisation plugin is in use but does 
>communicate, if it were, this would be treated differently. 
>- I would for example use it like [[ ]] but to trigger a button to 
>create the tiddler from a template
>- Or 〖task This inline 〗to create from the task template
>- Its the more visible version TT is asking for.
>
> However I do want you to retain ﹙ little﹚ for the same reason TT does not 
> want them, they are similar but different to ( ) and less visible. 
>
>- TT can just "*not use them"* if he does not like them (I say with 
>all due respect).
>
>
> Tony
>

-- 
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/fd88d292-d4a4-43ef-a974-34a8a1dc24e6o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I would be keen to see these additional inline glyphs made available. They 
look like a fusion of [ ] and ( )

It would be ideal for mark-up that involves links or buttons and where the 
content is considered a title.

*A line with〖 This inline 〗and more


   - They also look good when no customisation plugin is in use but does 
   communicate, if it were, this would be treated differently. 
   - I would for example use it like [[ ]] but to trigger a button to 
   create the tiddler from a template
   - Or 〖task This inline 〗to create from the task template
   - Its the more visible version TT is asking for.

However I do want you to retain ﹙ little﹚ for the same reason TT does not 
want them, they are similar but different to ( ) and less visible. 

   - TT can just "*not use them"* if he does not like them (I say with all 
   due respect).


Tony

-- 
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/7ae0fa0e-b0c5-43ab-a2db-3504c994155fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Question,

If other glyphs and characters could be selected could we actually redefine 
existing mark-up with customise?
\customise glyph="*" parameters

*This would then take on the new definition here?

I raise this because this us what the current double underscore is 
effectively doing.

An example I may use if this was possible is to add underline or bold to 
H1/H2

This would allow redefinition of mark-up already in a text perhaps even 
making it behave like another mark-up language.
and additions like
\customise glyph="-" _element="li"

- to accept bullets pasted from GitHub


Tones

-- 
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/0a8dce1e-9e25-40b2-b8bf-e7170b501f56o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Just for clarification the double underscore (not underscore) is used, does 
this not clash with its existing use?, or is this intentional?

It is available on most keyboards.

Regards
Tony


On Saturday, 31 October 2020 00:55:25 UTC+11, PMario wrote:
>
> Hi folks,
>
> I'd like to discuss with you the table syntax as shown in
>
> \customize tick=table _element=table _endString="/endTable" _mode=block
> \customize tick=caption _element=caption
>
> \customize tick=! _element=th 
>
> \customize tick=cell _element=td _classes=".hl"
> \customize tick _use=cell
>
> \customize angle="===row" _element=tr _mode=block _endString="---"
> \customize angle=cmulti _element=td _classes=".hl" _mode=block 
> \customize angle=| _use=cmulti
>
> ´table ´caption Some caption text
> »===row
> ´! header 1
> ´! header 2
> ´! header 3
> ---
> »===row
> »| 1 text 
>
> »| 12 text «  and  » 
>
> »|
> * cell 13 text
> * line 2 
> * line 3 
> ---
> »===row
> »| 2 text 
>
> »| 22 text 
>
> »| 23 text 
>
> ---
> /endTable
>
> and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table
>
> Do you think it could be used as a default, shipped with the plugin. .. 
> The CSS for multiline and eg: bullet lists will need some adjustment .. 
>
> tick-cells are use for single line cells terminated by \n
> angle-cells are used for multi, block like cells terminated by \n\n
>
> »===row
>ends with 
> ---
>
> -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/ad5cc2f9-5494-4ba9-af57-3ced3be597dco%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

I think it would be useful to include such "compound customisations" with 
the plugin or at lest on the plugins website. Although perhaps it could be 
an optional item that requires tagging.

Having used html tables within wikitext for so long, I find it easier to 
follow a html table format, and simple closures, as follows;

\customize tick=table _element=table _endString="/table" _mode=block
\customize tick=caption _element=caption

\customize tick=th _element=th

\customize tick=td _element=td _classes=".hl"  _mode=block

\customize tick="tr" _element=tr _mode=block _endString="/tr"

´table ´caption Some caption text
´tr
´th header 1
´th header 2
´th header 3
/tr


´tr
´td 1 text
´td 12 text «  and  »
´td
* cell 13 text
* line 2
* line 3
/tr


´tr
´td 2 text
´td 22 text
´td 23 text
/tr
/table

However if we are considering distributing or documenting "compound 
customisations" I would be tempted to extend my table to to include a lot 
more such and head/foot/body, a list widget for both rows and columns, as I 
would do this for myself anyway.

Perhaps your table responding to classic tiddlywiki tables AND one 
responding to html tables included would make sense?

Tony



On Saturday, 31 October 2020 00:55:25 UTC+11, PMario wrote:
>
> Hi folks,
>
> I'd like to discuss with you the table syntax as shown in
>
> \customize tick=table _element=table _endString="/endTable" _mode=block
> \customize tick=caption _element=caption
>
> \customize tick=! _element=th 
>
> \customize tick=cell _element=td _classes=".hl"
> \customize tick _use=cell
>
> \customize angle="===row" _element=tr _mode=block _endString="---"
> \customize angle=cmulti _element=td _classes=".hl" _mode=block 
> \customize angle=| _use=cmulti
>
> ´table ´caption Some caption text
> »===row
> ´! header 1
> ´! header 2
> ´! header 3
> ---
> »===row
> »| 1 text 
>
> »| 12 text «  and  » 
>
> »|
> * cell 13 text
> * line 2 
> * line 3 
> ---
> »===row
> »| 2 text 
>
> »| 22 text 
>
> »| 23 text 
>
> ---
> /endTable
>
> and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table
>
> Do you think it could be used as a default, shipped with the plugin. .. 
> The CSS for multiline and eg: bullet lists will need some adjustment .. 
>
> tick-cells are use for single line cells terminated by \n
> angle-cells are used for multi, block like cells terminated by \n\n
>
> »===row
>ends with 
> ---
>
> -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/53fb6198-c3bd-41f0-b02e-e1ddbe403d95o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi folks,

I'd like to discuss with you the table syntax as shown in

\customize tick=table _element=table _endString="/endTable" _mode=block
\customize tick=caption _element=caption

\customize tick=! _element=th 

\customize tick=cell _element=td _classes=".hl"
\customize tick _use=cell

\customize angle="===row" _element=tr _mode=block _endString="---"
\customize angle=cmulti _element=td _classes=".hl" _mode=block 
\customize angle=| _use=cmulti

´table ´caption Some caption text
»===row
´! header 1
´! header 2
´! header 3
---
»===row
»| 1 text 

»| 12 text «  and  » 

»|
* cell 13 text
* line 2 
* line 3 
---
»===row
»| 2 text 

»| 22 text 

»| 23 text 

---
/endTable

and: https://wikilabs.github.io/editions/custom-markup/#test-dave-table

Do you think it could be used as a default, shipped with the plugin. .. The 
CSS for multiline and eg: bullet lists will need some adjustment .. 

tick-cells are use for single line cells terminated by \n
angle-cells are used for multi, block like cells terminated by \n\n

»===row
   ends with 
---

-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/4d80861d-3ad5-4b05-83ef-f313fe6ca11co%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Go how you want, but my understanding comes from the more "modern use" 
noted later in the Wikipedia entry, truthfully a leading one may confuse me 
ans many others given this;

*The pilcrow is used in desktop publishing software 
>  such as 
> desktop word processors 
>  and page layout 
>  programs to mark the presence 
> of a carriage return 
>  control character 
>  at the end of a 
> paragraph. It is also used as the icon 
>  on a toolbar 
>  button that shows or hides the 
> pilcrow and similar hidden characters, including tabs 
> , whitespace 
> , and page 
> breaks . In typing 
>  programs, it marks a return that one 
> must type.*


I have being keen to make a preview that acts as the aforementioned toolbar 
button would.

You are right to *"produce html output that is well formed", *I will return 
to reviewing the html my tests generate. I not you have many of my prior 
examples in test tiddlers, thanks its a helpful reference. 

Tony

On Friday, 30 October 2020 15:44:29 UTC+11, PMario wrote:
>
> On Friday, October 30, 2020 at 1:09:16 AM UTC+1, TonyM wrote:
>
> Only one issue you may have overlooked, or I missed your answer. Rather 
>> than use pilcrow at the beginning of a line I would only use it at the end, 
>> if you don't see an "end of line only pragma" being possible as 
>> discussed in this reply 
>>  
>> then 
>> I would suggest the reverse pilcrow, as it indicates beginning of paragraph.
>>
>
> Have a look at this: https://en.wikipedia.org/wiki/Pilcrow
>
> Pilcwrow is used at the beginning of a new paragraph and by default stops 
> with \n\n in the customize implementation. ... Similar to TTs suggestion. 
> ... 
>
> I did try to implement pilcrow / reverse pilcrow as inline markers too. .. 
> BUT it produces really strange and invalid HTML code. Ps inside SPANs 
> inside Ps if stuff was nested. .. So I did move it to "block" like syntax, 
> where it produces some predictable html output. 
>
> One of my goals still is, to produce html output that is well formed. ... 
> There is a pending PR and some discussion at GitHub, that try to fix the 
> problems with too many Ps in TW wikitext output. Especially in the UI 
> sections, where it causes theming problems. 
>
> -m
>

-- 
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/47d77f8a-6a93-4fdb-8fb1-cd560fcaa1f8o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Friday, October 30, 2020 at 1:09:16 AM UTC+1, TonyM wrote:

Only one issue you may have overlooked, or I missed your answer. Rather 
> than use pilcrow at the beginning of a line I would only use it at the end, 
> if you don't see an "end of line only pragma" being possible as discussed 
> in this reply 
>  then 
> I would suggest the reverse pilcrow, as it indicates beginning of paragraph.
>

Have a look at this: https://en.wikipedia.org/wiki/Pilcrow

Pilcwrow is used at the beginning of a new paragraph and by default stops 
with \n\n in the customize implementation. ... Similar to TTs suggestion. 
... 

I did try to implement pilcrow / reverse pilcrow as an inline markers too. 
.. BUT it produces really strange and invalid HTML code. Ps inside SPANs 
inside Ps if stuff was nested. .. So I did move it to "block" like syntax, 
where it produces some predictable html output. 

One of my goals still is, to produce html output that is well formed. ... 
There is a pending PR and some discussion at GitHub, that try to fix the 
problems with too many Ps in TW wikitext output. Especially in the UI 
sections, where it causes theming problems. 

-m

-- 
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/153413bf-a8da-4bdd-b762-678052f69d2fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

What you have done is fantastic. I will focus on V 0.8.0 - 2020-10-29 From 
a testing and features arising point of view. 

I am Happy to stabilise with the current solution as a first release if you 
want.

My only urgency to raise the custom Glyphs is that your are aware of it as 
a possibility and desirable. However you have done more than enough to 
accommodate I, your own and TT's questions and imagination. Its a pleasure 
working with you.

Only one issue you may have overlooked, or I missed your answer. Rather 
than use pilcrow at the beginning of a line I would only use it at the end, 
if you don't see an "end of line only pragma" being possible as discussed 
in this reply 
 then 
I would suggest the reverse pilcrow, as it indicates beginning of paragraph.

Love your work as usual, and yes the combinatorial complexity is massive. 

We do need to draw *the line* somewhere. All we need to do is ensure *the 
line *does *not compromise the future* and I think you have that in control.

Regards
Tony

 


On Friday, 30 October 2020 05:49:26 UTC+11, PMario wrote:
>
> Hi Folks,
>
> There has been so much feedback lately, that I'm still a bit overwhelmed. 
> .. I need to read and re-read the infos several times. 
>
> At the moment we have maximum flexibility, except 
> user-glyph-configuration. ... But let us test, what we have atm. ... 
>
> I'll need to create a lot more automatic tests, to avoid regressions in 
> the future. Since "inline"-like configuration can do the same things as 
> "block"-like customs I think we have a lot to test ;)
>
> It may be even possible to reduce the number of used glyphs. ... BUT I 
> think there is enough variety to satisfy the users preferences. Especially 
> as every glyph can have unlimited "symbols"
>
> -m
>

-- 
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/cf49e815-2b82-4eab-a933-30c14274066bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Sorry about the overwhelming. I will try and simplify


>> *The attached local view template demonstrates the use of additional code 
>> in a specific tiddler. *
>>
>>- *In this case of you add the field local-viewtemplate to any 
>>tiddler in the edit view and a new editable field appears. This will be 
>>applied through the view template.*
>>- *Please try it, it is immensely useful for research and 
>>experimentation on view Template code.*
>>
>>
> *Hi Tony, *
>
> *I got it working, but I think I'm the wrong person here. The problem I 
> have with that approach is: I don't understand it. *
>
> *I can't see the usecase, because my philosophy is completely different in 
> this regard.*
>

*The use case is an instant view template*, that impacts on the current 
tiddler for ViewTemplate development and testing. Once tested you would 
move the code to a global viewTemplate and delete the local one, unless 
perhaps you had a bespoke view template for one tiddler.

The reason I suggest it, is we *could have a bespoke \customise wikitext 
pragma field*, for the same development purpose, for later globalisation if 
desired.

I can build it already I believe, If I can do it with a reference somehow 
to !!custom-pragma

\importcustom [[pragma-details]]


Regards
Tony 


> 
>
> For me only 1 multiline field exists: The text field. The tiddler is the 
> smallest element in TW. 
>
> If I need "combined multiline content" I think there should be different 
> stories. IMO the Streams concept 
>  is the way to go. In TW 
> 5.1.23 there will be some (invisible) elements, that will make working with 
> "combined tiddlers" and multiple stories easier. 
>
> As soon as I need a multiline field I think it is much easier to go the 
> multi-tiddler / multi-story way as shown in the video from 9:30 to 10:30 
>   
> TW 5.1.23 will contain some elements, that will make this approach easier. 
> ... BUT there is still more work to do. There are some open PRs and 
> discussions at GitHub.
>
> -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/7e24943c-249e-4736-a691-a6a8bc3f1304o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

An Idea, to avoid us returning to a solution which has no additional glyphs 
config, could be solved by providing a packaging solution, not unlike the 
bundler plugin. We can just select tiddlers with customise and bundle the 
definitions and custom definitions to ensure transferability.

Of importance here though, I am suggesting giving the vast majority of 
users, an appropriate set of pre-defined glyphs, they may never know you 
can define more. Being able to customise them, apply parameters and 
classes, use symbols etc... "is more than enough rope". But we know and we 
can innovate via this new Glyph mechaisium. If we can define a way to 
distribute a new glyph definition, perhaps in a separate file or plugin 
then a level of modularisation occurs, even allowing us to build the 
default glyphs in the same way. There is no harm if it demands a reload, we 
can force it in a glyph definition plugin, with customise wiki text as a 
dependency.

This customised wikitext solution is so powerful I think providing such an 
extencibility feature is wise, otherwise there will be too much pressure to 
update the core solution, and I do not want this to become a maintenance 
issue for you. 

As long as we can see what glyphs have being defined, it is possible to 
search for all tiddlers making use of that glyph, and advantage of using 
Unicode characters rarely found in content. If I go to export a tiddler 
with customised pragma, if I identify which defined pragma are in use in 
the current tiddler, and include their definitions, perhaps not the default 
(definitions), but also optionally the plugin as well. Then transfer 
becomes easy.

Now, I must declare knowing what customise can achieve so far, and the 
wealth of shiny Unicode characters, I am taken by the possibilities for 
writing my own content with any custom wikitext I desire. I really don't 
care if its transferable, people can read the rendered results, I can 
capture static HTML or deliver customisations in any Wiki I want. I am 
already thinking about a glyph for footnotes or extreme semantics like 

∴ This is the conclusion or therefore statement in my text
;This is another conclusion
:This will be helpful ∴ review and extend these ideas.
That my knowledge base can extract and I can globally reformat in one 
place. All by customising a meaningful glyph.

Single line mark-ups for questions, answers, therefore, to do, details, 
references, errors,  all triggered by glyph With customise 
wikitext these can be used to trigger tasks, tiddlers, workflows and more 
all from insertion of a single glyph.

By being able to choose the glyph we can customise meaningful single 
character mark ups in a highly semantic way, rather that having to remember 
a glyph/symbol pair.

This is after all offering a personal productivity solution, sufficient to 
be wiki specific, as much as, a feature for tiddlywiki for lots of wikis.

Regards
Tone=y


On Friday, 30 October 2020 03:15:20 UTC+11, PMario wrote:
>
> On Thursday, October 29, 2020 at 1:05:53 AM UTC+1, TonyM wrote:
>
> Just a thought, if the customise definition was to accept both glyph and 
>> symbol as parameters this may be an easier approach.
>> \customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight 
>> _classes=".highlight" _mode=inline
>> even an new \customise-def that accepts _glyphs and _glyphNames and 
>> \customise does not.
>>
>
> Those definitions will need to be done at startup time. 
>  
>
>> Then all the existing definitions would be transferred into this form, 
>> but could be altered.
>>
>
> That's right.
>
> Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent 
>> use such as 
>> \customise openenc _classes=".highlight-green"
>> In effect a redefinition, like the current customise.
>>
>> In the worst case there will need to be a start-up process that puts 
>> glyph definitions in a specific tiddler into a table, ie reload to add new 
>> glyphs.
>>
>
> That would need to happen. ... When \customize definitions are parsed, the 
> whole initialisation process is in the past. So there would need to be a 
> configuration tiddler, that contains the necessary definitions. 
>
> The problem is, that the user, which wants to define the config tiddler 
> would have to know exactly, how the parser works, to do the right things. 
> ... I think it will be an education / documentation problem. 
>  
>
>> Forgive me for interfering in this aspect of coding, which I am as yet 
>> unable to contribute to myself. I wish you had another "coder" (or more) 
>> sharing your effort.
>>
>
> I do have a little problem with too many different "glyphs". .. It may 
> also be a "tower of babel" problem, which could make interchanging content 
> much harder. ... So if something is hardcoded, all users have to use the 
> same "mechanisms". ... 
>  
>
>> I would just add to the general discussion, whilst global customise is a 
>> valuable tool, I can see customise being added

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi Folks,

There has been so much feedback lately, that I'm still a bit overwhelmed. 
.. I need to read and re-read the infos several times. 

At the moment we have maximum flexibility, except user-glyph-configuration. 
... But let us test, what we have atm. ... 

I'll need to create a lot more automatic tests, to avoid regressions in the 
future. Since "inline"-like configuration can do the same things as 
"block"-like customs I think we have a lot to test ;)

It may be even possible to reduce the number of used glyphs. ... BUT I 
think there is enough variety to satisfy the users preferences. Especially 
as every glyph can have unlimited "symbols"

-m

-- 
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/c2ed83ed-8cf1-4864-b077-2bda33c2cc54o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi,

Inline nesting seems to have a problem. 

-m

-- 
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/dfc96463-8c76-4529-8e4f-32270c2214a0o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

Hi,

V 0.8.0 - 2020-10-29

   - There are 4 "inline" like elements
  - __ underscore__, ﹙ little﹚, ⠒ braille⠶, /° slash°/
   - There are 6 "block" like elements
  - pilcrow: ¶, about: ≈, angle: », degree: °, tick: ´, single: ›
   
and it's crazy!

The "inline"-like elements do have predefined _endStrings but *all* the 
other parameters can be defined. 

There are 6 "block"-like elements now. pilcrow uses a P aragraph as default 
and terminates \n\n as default.

__underscore__ behaves exactly as the existing wikitext ... so it uses an 
html U element by default. This can be re-defined if needed. 

"braille" and "shlash" are nestable by default. 

Shortcut buttons and docs is missing. 
I didn't test all the possible combinations, since that's really a lot. ... 

Have a look at: 
https://wikilabs.github.io/editions/custom-markup/#test-underscore-mode-block:test-underscore-mode-block%20test-inline-small-bracket%20test-tonys-examples

WE WILL NEED TO SIMPLIFY THIS! ... but it's cool to play with it ;)

have fun!

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/d507143f-5a1a-426f-816d-0f586c439919o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Thursday, October 29, 2020 at 1:17:11 AM UTC+1, TonyM wrote:
>
> Gentlemen,
>
> The attached local view template demonstrates the use of additional code 
> in a specific tiddler. 
>
>- In this case of you add the field local-viewtemplate to any tiddler 
>in the edit view and a new editable field appears. This will be applied 
>through the view template.
>- Please try it, it is immensely useful for research and 
>experimentation on view Template code.
>
> Hi Tony, 
*I got it working*, but I think I'm the wrong person here. The problem I 
have with that approach is: I don't understand it. 

I can't see the usecase, because my philosophy is completely different in 
this regard. 



For me only 1 multiline field exists: The text field. The tiddler is the 
smallest element in TW. 

If I need "combined multiline content" I think there should be different 
stories. IMO the Streams concept 
 is the way to go. In TW 
5.1.23 there will be some (invisible) elements, that will make working with 
"combined tiddlers" and multiple stories easier. 

As soon as I need a multiline field I think it is much easier to go the 
multi-tiddler / multi-story way as shown in the video from 9:30 to 10:30 
  
TW 5.1.23 will contain some elements, that will make this approach easier. 
... BUT there is still more work to do. There are some open PRs and 
discussions at GitHub.

-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/5a69fe6a-bfe1-4400-891a-ac045e9c4f73o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Thursday, October 29, 2020 at 1:05:53 AM UTC+1, TonyM wrote:

Just a thought, if the customise definition was to accept both glyph and 
> symbol as parameters this may be an easier approach.
> \customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight 
> _classes=".highlight" _mode=inline
> even an new \customise-def that accepts _glyphs and _glyphNames and 
> \customise does not.
>

Those definitions will need to be done at startup time. 
 

> Then all the existing definitions would be transferred into this form, 
> but could be altered.
>

That's right.

Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent 
> use such as 
> \customise openenc _classes=".highlight-green"
> In effect a redefinition, like the current customise.
>
> In the worst case there will need to be a start-up process that puts glyph 
> definitions in a specific tiddler into a table, ie reload to add new glyphs.
>

That would need to happen. ... When \customize definitions are parsed, the 
whole initialisation process is in the past. So there would need to be a 
configuration tiddler, that contains the necessary definitions. 

The problem is, that the user, which wants to define the config tiddler 
would have to know exactly, how the parser works, to do the right things. 
... I think it will be an education / documentation problem. 
 

> Forgive me for interfering in this aspect of coding, which I am as yet 
> unable to contribute to myself. I wish you had another "coder" (or more) 
> sharing your effort.
>

I do have a little problem with too many different "glyphs". .. It may also 
be a "tower of babel" problem, which could make interchanging content much 
harder. ... So if something is hardcoded, all users have to use the same 
"mechanisms". ... 
 

> I would just add to the general discussion, whilst global customise is a 
> valuable tool, I can see customise being added to the specific tiddlers 
> that wish to use extended mark-up, so in many cases the scope will only be 
> the current tiddler. If a text contains a glyph the editor can just choose 
> another for their special mark-up, a small popup panel could list the 
> glyphs found in a tiddler.
>

If something is defined on a per tiddler basis, I don't see a big problem. 
... The problem for content interchange comes with global definitions. .. 
If users forget to export the global definitions and the tiddler don't 
contain any info, that there actually IS a global definition.

That's why at the beginning there had to be an \importcustom [[abc]]. If a 
tiddler contains this info. Everyone knows what to request. ...
 

> Another approach is using a custom type field, and the type which is 
> equivalent to a mime type also permits providing the character set.
>

At the moment the core TW doesn't know how to deal with custom mime-types, 
which basically makes it impossible to use them.

-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/ab2b2a4a-5d17-45d3-b07a-f3faef0f0a01o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Gentlemen,

The attached local view template demonstrates the use of additional code in 
a specific tiddler. 

   - In this case of you add the field local-viewtemplate to any tiddler in 
   the edit view and a new editable field appears. This will be applied 
   through the view template.
   - Please try it, it is immensely useful for research and experimentation 
   on view Template code.

I can see using this or something similar for the application of various 
customise 
definitions only on the local tiddler.

   - Keep in mind a local-customise field could contain also a transclusion 
   such as {{extended-markup}} to include a custom mark-up template, or 
\importcustom 
   [[pragma-details]]
   - I am still to make this work for customize, but Mario would know how 
   to of the top of his head.
   - Note the customised wiki would not apply if the text field were 
   transcluded elsewhere but we could have a template that does include the 
   local-template or local-customise in a Transclude (if it exists) eg 
   {{tiddlername||$:/template/render-with-custom-wikitext}} 

Regards
Tony
Regards
Tony

-- 
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/cbf1e047-0fe9-484f-b49c-a44c106066a4o%40googlegroups.com.


local-viewtemplate.json
Description: application/json

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,

Just a thought, if the customise definition was to accept both glyph and 
symbol as parameters this may be an easier approach.
\customise _glyph="〖" _glyphName="openenc" _endString="〗" _symbol=highlight 
_classes=".highlight" _mode=inline
even an new \customise-def that accepts _glyphs and _glyphNames and 
\customise does not.

Then all the existing definitions would be transferred into this form, but 
could be altered.
Accepting a _glyphName="openenc" (open enclosed brackets) for subsequent 
use such as 
\customise openenc _classes=".highlight-green"
In effect a redefinition, like the current customise.

In the worst case there will need to be a start-up process that puts glyph 
definitions in a specific tiddler into a table, ie reload to add new glyphs.

Forgive me for interfering in this aspect of coding, which I am as yet 
unable to contribute to myself. I wish you had another "coder" (or more) 
sharing your effort.

I would just add to the general discussion, whilst global customise is a 
valuable tool, I can see customise being added to the specific tiddlers 
that wish to use extended mark-up, so in many cases the scope will only be 
the current tiddler. If a text contains a glyph the editor can just choose 
another for their special mark-up, a small popup panel could list the 
glyphs found in a tiddler.

Another approach is using a custom type field, and the type which is 
equivalent to a mime type also permits providing the character set.

Regards
Tony

On Thursday, 29 October 2020 01:53:12 UTC+11, PMario wrote:
>
> On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>>
>> *Regarding User Possibility To Set Markup Glyphs?*
>>
>> TonyM wrote:
>>>
>>>
>>> *Question - customised Glyphs, a glyph too far?*
>>>
>>>- As you can see the wide range of glyphs available that have 
>>>meaning or structure makes me wish to ask if we could allow the user to 
>>>nominate glyphs either single (line/para/blocks) or pairs for inline or 
>>>block. ie customise the customise glyphs.
>>>
>>>
>>  Ciao TonyM & PMario
>>
>> IF this were possible I WOULD use it.
>>
>
> ... need to think about it. But it would make configuration a hell lot 
> more complex.
>  
>
>> Why? Because the kinds of Markup I do would benefit from me being able to 
>> choose glyphs VISUALLY SUITED to the purpose.
>> For instance, for simple paragraphs ...
>>
>> ¶ Start of a paragraph,
>> more of the same pargraph endedon the next line.
>> ⁋ <--- End String
>>
>> I understand if its not possible. 
>>
>
> It would be possible to use pilcrows as "start" and "end" of a paragraph, 
> but I don't understand why. 
>
> TW Pargraphs end with \n\n by default
>
> So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
> personally it is confusing, since Libre Office and Word use: ¶  as a 
> paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
> paragraph. ... So the reverse pilcrow feels completely wrong at that 
> position.
>
> *I could implement:*
>
> ¶ some text \n\n
>
> Since it would be the right thing to do. see: Wikipedia Pilcrow 
> . It would be easy to explain, 
> with the link to Wikipedia. It will create a HTML P tag by default.
>
> If you want you can define an _endString. ... Default would be \n\n
>
> -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/e1e3292d-d7ef-4bee-87e1-aad00b5c43e4o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[TonyM]

Mario,Josiah

¶
I would not bother with the use of pilcrow unless it was part of an end of 
line form of glyph only. Its key use would be to place a pilcrow in a large 
slab of text to force a pagarapgh break. if other glyphs depended on \n\n, 
it would be best to resolve these first if possible. There is a implied *new 
paragraph* that follows the ¶ that is sufficient in my view (as for this 
paragraph). If one was to have a start and end the appropriate method is a 
revers-pilcrow and pilcrow pair.

End of line only mark up, with selectable glyphs, Would allow someone like 
> me to define a glyph  "¶" as "br>" so insertion of ¶ would 
> render as a new paragraph "break". This provide the complement to beginning 
> of line and inline mark-up.

 
Arguably the ¶ could be given a definition that highlights the first word 
of the next (generated paragraph).
 
Josiah, I don't mind decent, however I disagree with the lack of visibility 
with "the" parenthesis, and value how the look. First with Custom wiki text 
present they disappear in the output. Secondly we can use the slightly 
different examples given. My point here is if something is not good enough 
⸨rather 
than exclude it⸩ find if there is a way to 〖 address 〗 it, such as ⁽ Here ⁾ 
or ₍ there ₎ remember as a rule already text contains ' " ` and other 
characters even less readable. The fact that a reader may not be able to 
tell the difference may actually be an advantage when no customisation is 
occurring.

If we have two (or more) open and close braces there is an opportunity to 
define one as non-operative in text that contains one of the other pairs. 
The point being the only reason they will be in use is because the writer 
chooses to.

I am actually keen to use such Unicode braces simply to delimit a piece of 
text, I would write separate macros to extract those ﹤keywords and phrases﹥ so 
delimited, independent of the current text even without the use of 
customise. However if such pairs are available to "custom wikitext" further 
automation or formatting can be done to automate this feature.

Tony


On Thursday, 29 October 2020 01:53:12 UTC+11, PMario wrote:
>
> On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>>
>> *Regarding User Possibility To Set Markup Glyphs?*
>>
>> TonyM wrote:
>>>
>>>
>>> *Question - customised Glyphs, a glyph too far?*
>>>
>>>- As you can see the wide range of glyphs available that have 
>>>meaning or structure makes me wish to ask if we could allow the user to 
>>>nominate glyphs either single (line/para/blocks) or pairs for inline or 
>>>block. ie customise the customise glyphs.
>>>
>>>
>>  Ciao TonyM & PMario
>>
>> IF this were possible I WOULD use it.
>>
>
> ... need to think about it. But it would make configuration a hell lot 
> more complex.
>  
>
>> Why? Because the kinds of Markup I do would benefit from me being able to 
>> choose glyphs VISUALLY SUITED to the purpose.
>> For instance, for simple paragraphs ...
>>
>> ¶ Start of a paragraph,
>> more of the same pargraph endedon the next line.
>> ⁋ <--- End String
>>
>> I understand if its not possible. 
>>
>
> It would be possible to use pilcrows as "start" and "end" of a paragraph, 
> but I don't understand why. 
>
> TW Pargraphs end with \n\n by default
>
> So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
> personally it is confusing, since Libre Office and Word use: ¶  as a 
> paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
> paragraph. ... So the reverse pilcrow feels completely wrong at that 
> position.
>
> *I could implement:*
>
> ¶ some text \n\n
>
> Since it would be the right thing to do. see: Wikipedia Pilcrow 
> . It would be easy to explain, 
> with the link to Wikipedia. It will create a HTML P tag by default.
>
> If you want you can define an _endString. ... Default would be \n\n
>
> -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/efb10bf8-eba1-4cea-8fc5-36b85f83266fo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[PMario]

On Wednesday, October 28, 2020 at 1:50:44 PM UTC+1, @TiddlyTweeter wrote:
>
> *Regarding User Possibility To Set Markup Glyphs?*
>
> TonyM wrote:
>>
>>
>> *Question - customised Glyphs, a glyph too far?*
>>
>>- As you can see the wide range of glyphs available that have meaning 
>>or structure makes me wish to ask if we could allow the user to nominate 
>>glyphs either single (line/para/blocks) or pairs for inline or block. ie 
>>customise the customise glyphs.
>>
>>
>  Ciao TonyM & PMario
>
> IF this were possible I WOULD use it.
>

... need to think about it. But it would make configuration a hell lot more 
complex.
 

> Why? Because the kinds of Markup I do would benefit from me being able to 
> choose glyphs VISUALLY SUITED to the purpose.
> For instance, for simple paragraphs ...
>
> ¶ Start of a paragraph,
> more of the same pargraph endedon the next line.
> ⁋ <--- End String
>
> I understand if its not possible. 
>

It would be possible to use pilcrows as "start" and "end" of a paragraph, 
but I don't understand why. 

TW Pargraphs end with \n\n by default

So the "reversed pilcrow" ⁋ <--- End String is redundant and for me 
personally it is confusing, since Libre Office and Word use: ¶  as a 
paragraph marker. ... It may be wrong, but it is shown at the *end* of a 
paragraph. ... So the reverse pilcrow feels completely wrong at that 
position.

*I could implement:*

¶ some text \n\n

Since it would be the right thing to do. see: Wikipedia Pilcrow 
. It would be easy to explain, with 
the link to Wikipedia. It will create a HTML P tag by default.

If you want you can define an _endString. ... Default would be \n\n

-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/861387d1-7ccc-490e-b75c-b55e76b1ea9bo%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Regarding User Possibility To Set Markup Glyphs?*

TonyM wrote:
>
>
> *Question - customised Glyphs, a glyph too far?*
>
>- As you can see the wide range of glyphs available that have meaning 
>or structure makes me wish to ask if we could allow the user to nominate 
>glyphs either single (line/para/blocks) or pairs for inline or block. ie 
>customise the customise glyphs.
>
>
 Ciao TonyM & PMario

IF this were possible I WOULD use it.

Why? Because the kinds of Markup I do would benefit from me being able to 
choose glyphs VISUALLY SUITED to the purpose.
For instance, for simple paragraphs ...

¶ Start of a paragraph,
more of the same pargraph endedon the next line.
⁋ <--- End String

I understand if its not possible. 

I assume the current approach is hard-coded JS?

Just a thought to say TonyM & I on this idea concur.

Very best wishes
Josiah

-- 
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/fa7cf420-eb06-41a4-b63f-f9e4cbf44904o%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Block & Inline are Different Things. Having separate definition spaces 
remains a good idea. *

Ciao PMaio & TonyM

PMario wrote:
>
> As I do read the requests, I think we shouldn't make a difference between 
> \customize and \customize inline  But this could cause a lot more 
> consistency problems, like:
>
> ´d ´s some text<-- only works that way because I liked it. 
>
> With strict rules it would need to look like this:
>
> ´d
> ´s some text
> some text
>    <--* _endString*
>

I think the distinction between INLINE & BLOCK remains valid. Of course you 
can argue one can glide one into the other. But I'd need convincing that 
the basic distinction should be messed with. Customize each separately. You 
could still use \customize to change behaviors for any element.

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/bf731c1f-bb52-4d42-8943-18316163302do%40googlegroups.com.

[twdev] Re: Custom markup (continued 4)

[@TiddlyTweeter]

*Note On EndString & Mode -- Agreed & More*

PMario wrote
>
>
> _endString will be _not_ configurable. 
>
> _mode has to be fixed to inline
>

Makes much sense.

INLINE, much more than BLOCK, is about* fluidity of writing. *
A simple approach looks appropriate.

In line with that I'm most concerned that markup is as COMPACT AS POSSIBLE 
(i.e. single character open & close strings). The MAIN innovations in your 
approach are ...

1 - enabling the use of HTML INLINE ELEMENTS (eventually).

 and

2 - NESTING. 

IMO this combo will do more to AID WRITERS than any other aspect of Custom 
Markup.

It is a far superior to current Inline WikiText which is an over verbose 
and somewhat blunt instrument.

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/b0008013-2cac-4099-98d5-ad1aa9e52863o%40googlegroups.com.