Hi all, I'm very impressed with this project. I'm using the Lagrange client by Jaakko Ker?nen and it's very beautiful. But I noticed an oversight. Lagrange handles images absolutely great: they're only downloaded when I click on them. And I can (barely) live without inline links. But italics are just too important for writing in the Latin script (note that I don't really care about bold face). Other writing systems may have their own way of conveying emphasis, but for the Latin script it's italics. The Gemini FAQ [1] itself already shows the issue: the heading for section 2.3 needed italics, but none were available, so it uses asterisks for emphasis. This does not look good in the otherwise very slick Lagrange. I don't think the ability to mark emphasis is likely to lead to abuse. Also, even if you plan on primarily interacting with Gemini in your terminal, let me point out that a lot of terminals support italics nowadays. And if your terminal doesn't, it can just ignore it. Now, one way out of this problem is to use Unicode's support for italics [2]. You could maybe argue that it should be the job of the text encoding to encode emphasis and not the job of the markup. But I don't have the impression that this is particularly well encoded in Unicode. And I think, for example, Cyrillic is missing from it. So, I hope you'll consider adding markup for emphasis, even if it will complicate the client implementation. One option is maybe to just make rendering emphasis *optional*. The specification could say that surrounding asterisks (*like this*) denote emphasis, but if a client doesn't want to render it, they could just display the asterisks. Cheers, Thomas [1]: gemini://gemini.circumlunar.space/docs/faq.gmi [2]: https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols
On Mon, 09 Nov 2020 20:00:51 +0000 "Thomas M" <thomas5max at gmail.com> wrote: > So, I hope you'll consider adding markup for emphasis, even if it will > complicate the client implementation. It would be the only markup that isn't entirely line prefix based and would complicate parsing a lot potentially invalidating straight forward techniques that clients are already using. Rendering something like
On Mon, Nov 9, 2020 at 3:41 PM Thomas M <thomas5max at gmail.com> wrote: > Now, one way out of this problem is to use Unicode's support for italics > ??? ??????, ?????? ?? ??? ???? ?? ?? ?????! I don't know how that's going to look to you, but for me the word "really" is just horribly badly kerned. What is more, the ! is completely upright because it has no math-italic equivalent. I think the client needs to decide whether to interpret ASCII inline markup of this kind. The spec says "Authors should not expect to exercise any control over the precise rendering of their text lines, only of their actual textual content", but a hint is not exercising precise control IMO. Any client that does this must leave the asterisks (or slashes, or whatever) in place, though; otherwise it has failed its basic duty of displaying all the content, subject only to resource limitations. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. --Edsger Dijkstra -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/ce1a bd77/attachment-0001.htm>
On 11/9/20 9:20 PM, Philip Linde wrote: > Rendering something like > *this* as italic text may also be surprisingly error prone, considering > other contexts in which one might want to use "*" and the different > sequences of text one might want to emphasize. It's something Markdown > parsers frequently get wrong, or at the very least causes unintuitive > problems. Thunderbird has a nice collection of issues logged over the years related to text formatting in plain text messages. It is indeed quite tricky, but if a client wanted to implement it I'd suggest looking into the Thunderbird test suite as a starting point. Also on the subject of *this* being italic I do want to point out that that choice of formatting for the markup is uniquely Markdown oriented. Most other plain text systems interpret *this* as bold and /this/ as italic and _this_ as underlined. We have a lot of Markdown influence in gemtext, but authors coming from other domains may find some surprises in various clients. If a client does choose to implement this as an optional add-on, please continue to show the characters when you style the text. In the case your parsing algorithm is incorrect the content will still be present and we can figure it out.
> I don't think the ability to mark emphasis is likely to lead to abuse. > Also, even if you plan on primarily interacting with Gemini in your > terminal, let me point out that a lot of terminals support italics > nowadays. And if your terminal doesn't, it can just ignore it. I don't know if this has been pointed out before, but you can get rendering similar to man pages (which has things like bold and underline IIRC) by using troff; it should I think be fairly easy to parse, although I have not tried it myself. The beautiful thing of troff in this context is that there is also a designated MIME type text/troff [RFC4263]; they also have a https-site [TROFF]. [RFC4263] https://www.iana.org/go/rfc4263 [TROFF] https://troff.org/
On Mon, 9 Nov 2020 21:57:02 +0000 James Tomasino <tomasino at lavabit.com> wrote: > Thunderbird has a nice collection of issues logged over the years related to text formatting in plain text messages. It is indeed quite tricky, but if a client wanted to implement it I'd suggest looking into the Thunderbird test suite as a starting point. That seems like a very good starting point. > Also on the subject of *this* being italic I do want to point out that that choice of formatting for the markup is uniquely Markdown oriented. Most other plain text systems interpret *this* as bold and /this/ as italic and _this_ as underlined. We have a lot of Markdown influence in gemtext, but authors coming from other domains may find some surprises in various clients. The /italics/ style has the unfortunate side effect of producing false positives for quite plausible Unix paths, e.g. /etc/. This has never been a problem in the settings I use this style of implying typography (mostly IRC) because the input isn't typically transformed and is presented as written. For transformed text, I personally prefer a style where the notion of emphasis is decoupled from the typographical choice of how to represent it. > If a client does choose to implement this as an optional add-on, please continue to show the characters when you style the text. In the case your parsing algorithm is incorrect the content will still be present and we can figure it out. Another good suggestion. From my reading there is no question that such an implementation would conform to the existing spec. As a more general solution, a client could allow the user to specify formatting for different sequences within the normal text lines using regular expressions. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/0e61 7f40/attachment.sig>
Just to add a wrinkle, another terribly hacky thing you can do is use raw terminal escapes to encode when you want italic and bold and underline, as well as different colors, if you just want to. However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent! -- ~ acdw acdw.net | breadpunk.club/~breadw
On Mon, Nov 9, 2020 at 6:46 PM Philip Linde <linde.philip at gmail.com> wrote:
> The /italics/ style has the unfortunate side effect of producing false
> positives for quite plausible Unix paths, e.g. /etc/.
Such markup should really only be recognized if there is whitespace or the
beginning of the line before it and whitespace, the end of the line, or
sentence-ending punctuation after it. One advantage of _ is that it is not
normally used in running text.
This has never
> been a problem in the settings I use this style of implying typography
> (mostly IRC) because the input isn't typically transformed and is
> presented as written
There are IRC clients that interpret it.
On Mon, Nov 9, 2020 at 6:52 PM acdw <acdw at acdw.net> wrote:
> However, I think it is a sign of stronger writing if an author is able to
> convey their meaning without resorting to what's essentially metadata in
> their text. Use syntax, word choice, and punctuation to express your
> intent!
Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
1) Titles of books, movies, magazines, and other stand-alone works.
2) Scientific names of plants and animals.
3) Terms being introduced for the first time.
4) In narrative, the thoughts of a character.
5) Words being used as examples of themselves. ("The word _the_ is a
definite article.")
6) Names of ships.
John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
When I'm stuck in something boring where reading would be impossible or
rude, I often set up math problems for myself and solve them as a way
to pass the time. --John Jenkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201109/e505
9e7f/attachment.htm>
On Mon, 09 Nov 2020 23:51:43 +0000 acdw <acdw at acdw.net> wrote: > Just to add a wrinkle, another terribly hacky thing you can do is use raw terminal escapes to encode when you want italic and bold and underline, as well as different colors, if you just want to. I enjoy the idea for its ingenuity, but I don't particularly look forward to having to implement a terminal emulation layer in my GUI client :) > However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent! Good point. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/cb2b 250c/attachment-0001.sig>
It was thus said that the Great John Cowan once stated:
>
> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>
> 1) Titles of books, movies, magazines, and other stand-alone works.
>
> 2) Scientific names of plants and animals.
>
> 3) Terms being introduced for the first time.
>
> 4) In narrative, the thoughts of a character.
>
> 5) Words being used as examples of themselves. ("The word _the_ is a
> definite article.")
>
> 6) Names of ships.
7) Foreign words
8) Direct thoughts---example: _Is a gom jabbar something of Arrakis I must
know before I go there?_ he wondered.
-spc (The example is from Dune, of which about a third is the direct
thoughts of the characters ... )
On 11/9/20 6:59 PM, Sean Conner wrote:
> It was thus said that the Great John Cowan once stated:
>>
>> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>>
>> 1) Titles of books, movies, magazines, and other stand-alone works.
>>
>> 2) Scientific names of plants and animals.
>>
>> 3) Terms being introduced for the first time.
>>
>> 4) In narrative, the thoughts of a character.
>>
>> 5) Words being used as examples of themselves. ("The word _the_ is a
>> definite article.")
>>
>> 6) Names of ships.
>
> 7) Foreign words
>
> 8) Direct thoughts---example: _Is a gom jabbar something of Arrakis I must
> know before I go there?_ he wondered.
>
> -spc (The example is from Dune, of which about a third is the direct
> thoughts of the characters ... )
>
Fair enough on all this --- but you know what's funny? I can tell where
the thoughts begin and end by the use of the formatting characters _ or
Thomas M <thomas5max at gmail.com> wrote: > Other writing systems may have their > own way of conveying emphasis, but for the Latin script it's italics. > Other ways of conveying emphasis include: (in no particular order)
On Mon, Nov 09, 2020 at 11:15:54PM +0000, Johann Galle said unto me: > I don't know if this has been pointed out before, but you can get > rendering similar to man pages (which has things like bold and underline > IIRC) by using troff; it should I think be fairly easy to parse, > although I have not tried it myself. The beautiful thing of troff > in this context is that there is also a designated MIME type > text/troff [RFC4263]; they also have a https-site [TROFF]. I think that it's reasonable to suggest that clients implement a form of rich text other than text/gemini. I don't think we need to bloat text/gemini to support every use case, instead I think we should encourage a set of alternatives. Reviewing the Wikipedia list of document markup languages[1] I'd lean towards TROFF or LaTeX. They are both mature and reasonably well defined formats. LaTeX has the advantage of being a target for several document preprocessors (eg: pandoc[2]) so it need not be authored in directly. --Matt [1]: https://en.wikipedia.org/wiki/List_of_document_markup_languages [2]: https://pandoc.org -- Matthew Ernisse matt at going-flying.com https://www.going-flying.com/ gemini://going-flying.com/
On Tue, 10 Nov 2020 11:04:37 -0500 Matthew Ernisse <matt at going-flying.com> wrote: > I think that it's reasonable to suggest that clients implement a form of > rich text other than text/gemini. I don't think we need to bloat text/gemini > to support every use case, instead I think we should encourage a set of > alternatives. Does the client itself really need to do this? Allow the configuration of MIME type handlers that delegate the task to other applications and it's no longer strictly necessary, but would the user experience suffer? > Reviewing the Wikipedia list of document markup languages[1] I'd lean towards > TROFF or LaTeX. They are both mature and reasonably well defined formats. > LaTeX has the advantage of being a target for several document preprocessors > (eg: pandoc[2]) so it need not be authored in directly. Those formats would both be a hard no for me. If the goal of Gemini is to be a protocol that makes the implementation of a client and server simple, I don't think that recommending the inclusion of full typesetting systems is reasonable. A full distribution of LaTeX in particular can easily eat hundreds of megabytes, even gigabytes. -- Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201110/db2c 77ab/attachment.sig>
>> I think that it's reasonable to suggest that clients implement a form of >> rich text other than text/gemini. I don't think we need to bloat text/gemini >> to support every use case, instead I think we should encourage a set of >> alternatives. > > Does the client itself really need to do this? No, I don't think that clients need to do this themself. They could if they want to, but they could just as well delegate it to existing programs. To that end my original verbalisation was not really good because the gemini client should not be concerned with how easy it is to parse a different markup language. > Allow the configuration of MIME type handlers that delegate the task to other > applications and it's no longer strictly necessary, Exactly that. For example with text/troff a client could use nroff as a backend. > but would the user experience suffer? I don't see how the user experience should suffer, except for maybe installation on a platform where troff/nroff/groff/etc. is not available. That said, there is even a version of groff for Windows. And unixoids should also covered obviously. Of course it would probably be easier for terminal-based gemini clients than for graphical based clients to implement something like this. >> Reviewing the Wikipedia list of document markup languages[1] I'd lean towards >> TROFF or LaTeX. They are both mature and reasonably well defined formats. >> LaTeX has the advantage of being a target for several document preprocessors >> (eg: pandoc[2]) so it need not be authored in directly. > > Those formats would both be a hard no for me. ... > A full distribution of LaTeX in particular can easily eat hundreds of > megabytes, even gigabytes. I agree that LaTeX is probably overkill for this but seeing that troff or better nroff were designed pretty similar to text/gemini, macros start at the start of the line etc. its really quite simple. > If the goal of Gemini is to be a protocol that makes the implementation of a > client and server simple, I don't think that recommending the inclusion of > full typesetting systems is reasonable. At least for me this was not the point at all. It was more a recommendation that people who want other formatting with italics etc. could use another MIME type and not have to discuss endlessly on the mailing list and getting nowhere. The degree of including it into the standard to be able to use it is already big enough: You can specify which MIME type the response is. It is only a problem if the respective client does not implement that. And I think it depends on how deeply people want to use other formatting than provided by text/gemini if this gets more widespread usage in documents, and if that happens, clients will start to implement it too.
On Tue, Nov 10, 2020 at 05:59:29PM +0100, Philip Linde said unto me: > Does the client itself really need to do this? Allow the configuration > of MIME type handlers that delegate the task to other applications and > it's no longer strictly necessary, but would the user experience suffer? I'd say it's perfectly reasonable to leave the implementation details up to the client. I'd be perfectly happy if a terminal client went and supported mailcap(5) for example. > Those formats would both be a hard no for me. If the goal of Gemini is > to be a protocol that makes the implementation of a client and server > simple, I don't think that recommending the inclusion of full > typesetting systems is reasonable. A full distribution of LaTeX in > particular can easily eat hundreds of megabytes, even gigabytes. The implementation details ultimatly are up to the client author, as I say above if they want to just shell out to a command that's fine. The point is that it seems like the desire to extend text/gemini keeps coming up, so to avoid continuing to kick the can in a circle an alternate path may be to provide guidance to client authors so we can also provide guidance to textual authors that desire/require the extra expression. --Matt -- Matthew Ernisse matt at going-flying.com https://www.going-flying.com/
Matthew Ernisse <matt at going-flying.com> wrote: > On Mon, Nov 09, 2020 at 11:15:54PM +0000, Johann Galle said unto me: > > I don't know if this has been pointed out before, but you can get > > rendering similar to man pages (which has things like bold and > > underline IIRC) by using troff; it should I think be fairly easy to > > parse, although I have not tried it myself. The beautiful thing of > > troff in this context is that there is also a designated MIME type > > text/troff [RFC4263]; they also have a https-site [TROFF]. > I think that it's reasonable to suggest that clients implement a form > of rich text other than text/gemini. I don't think we need to bloat > text/gemini to support every use case, instead I think we should > encourage a set of alternatives. The further discussion of this point has seemed to assume a need to implement all of troff (and then spun off into LaTeX). I'd like to propose an alternative: the tiniest subset of it. Specifically: .I "italic text" optional-suffix optional-prefix E.g., this contrived example with a poor use of parentheses: ---- "I think we should represent italics .I "somehow" !" she said. .I "After all, this is a medium designed for writing." ) ( ---- would yield (where *this* is italicized): ---- "I think we should represent italics *somehow*!" she said. (*After all, this is a medium designed for writing.*) ---- As with troff, .I would *not* add line breaks. Unlike troff, this should *only* have the line-based option, and not the option to make it apply to all further text until the next line beginning with ".R". That does make writing a whole italicized paragraph or page more cumbersome, but that's a pretty unusual use case. Incidentally, troff is a topic likely to interest those into gemini: it's a far more lightweight typesetting system than LaTeX, though it has its limitations, and like text/gemini it is very much line-based. It also follows the rule that (almost) any formatting command should be short and at the start of the line. Also, I do recognize that this idea is going to get shot down as paving the way for more extensibility, though we already have things like verbatim blocks and what have you (which are more esoteric than italic, so I don't buy the "we shouldn't support every use case" argument. It's far more common to emphasize words, to write titles of works, and so forth, than it is to do ASCII art (not that there's anything wrong with ASCII art; it's great) or present code blocks (the current demographics of the medium notwithstanding)). As to using CAPS LOCK as a substitute for italics, that is just not feasible for anything longer than a word or two. OBSERVE, AS YOU READ THIS PARAGRAPH, THAT IT IS LESS COMFORTABLE TO READ THAN ONE WRITTEN WITH STANDARD TYPOGRAPHY. EVEN THE ROMANS FINALLY GAVE IN AND INVENTED MINISCULE LETTERS FOR THEIR ALPHABET, AND THAT'S AFTER RESISTING FOR CENTURIES THE IDEA OF EVEN USING SPACES OR CLAUDIAN DOTS BETWEEN WORDS, SO LITTLE DID THEY CARE ABOUT READABILITY. Using *emphasis* is a pretty acceptable solution most of the time, I think, but it does fall apart a bit with longer passages or titles:
Ivy Foster <escondida at iff.ink> writes:
> Also, I do recognize that this idea is going to get shot down as
> paving the way for more extensibility, though we already have things
> like verbatim blocks and what have you (which are more esoteric than
> italic, so I don't buy the "we shouldn't support every use case"
> argument. It's far more common to emphasize words, to write titles of
> works, and so forth, than it is to do ASCII art (not that there's
> anything wrong with ASCII art; it's great) or present code blocks (the
> current demographics of the medium notwithstanding)).
Early on, before gemtext existed in its current form, I was pushing to
include inline emphasis (like Markdown; in fact, I was pushing to use a
strict subset of Markdown for Gemini documents). The reason I lost that
argument was because it substantially complicates the implementation of
clients, and if you use "*" both for inline emphasis and links, then you
run into a lot of ambiguities that various Markdown implementations
face. But it's not that it's not wanted, or out of scope (in the way
that, for example, color specification would be).
Thought experiment: we agree to implement inline emphasis, using some
set of markers on either side of a range of text. To simplify
implementation, the emphasis must be within a single line of text (not a
problem since we use long lines and let clients wrap them). Emphasis
markers are not allowed in any line types except plain and list. The
markers should be ones that are commonly/historically used in plain-text
emails. Which markers should we use?
We can't use '*', because it would be ambiguous at the beginning of
lines. We can't use '/', because it is ambiguous with Unix paths. We can
use '_', but it's less used (to imply underlines). I'm open to
suggestions.
Clients would be free to represent this emphasis in any way suitable for
their display, including but not limited to italics. Not doing anything,
and leaving the emphasis markers in place, remains a valid
implementation. Implementations that _do_ use some kind of text
properties, like italics, are free to leave the emphasis markers in the
output, or remove them.
Any thoughts on this? It shouldn't be too much of a barrier to
implementation, because a) existing clients that do nothing are all
still in-spec, and b) the restriction on emphasis crossing lines means
that you can simply implement it with a regex, after you first determine
the line type.
A reminder: this is just a thought experiment, not yet an argument that
it should be implemented.
--
Jason McBrayer | ?Strange is the night where black stars rise,
jmcbray at carcosa.net | and strange moons circle through the skies,
| but stranger still is lost Carcosa.?
| ? Robert W. Chambers,The King in Yellow
On Thu Nov 12, 2020 at 12:18 PM +03, Jason McBrayer wrote: > Which markers should we use? [...] We can use '_', but it's less used > (to imply underlines). I'm open to suggestions. Using '_' would also conflict with snake_cased_variables in various programming contexts, which would also require the addition of a "inline preformatted" marker, which probably would complicate this even more. -- Have a nice /(day|night|week(end)?)/ ~ Ecmel B. Canl?er ~
> On Nov 12, 2020, at 15:58, Ecmel Berk Canl?er <me at ecmelberk.com> wrote: > > On Thu Nov 12, 2020 at 12:18 PM +03, Jason McBrayer wrote: >> Which markers should we use? [...] We can use '_', but it's less used >> (to imply underlines). I'm open to suggestions. > > Using '_' would also conflict with snake_cased_variables in various > programming contexts, which would also require the addition of a "inline > preformatted" marker, which probably would complicate this even more. Considering we have the full power of Unicode at our disposal -Thomas mentioned italicized math symbols previously- perhaps one could use some fancy combining diacritic ala "combining low line" at U+0332 to achieve the same effect: https://en.wikipedia.org/wiki/Underscore#Unicode My 2?: enough fidgeting with text/gemini. Let us try to use what we have in creative, forward looking ways ??
On Thu, Nov 12, 2020 at 10:16 AM Petite Abeille <petite.abeille at gmail.com> wrote: > > > On Nov 12, 2020, at 15:58, Ecmel Berk Canl?er <me at ecmelberk.com> wrote: > > > > On Thu Nov 12, 2020 at 12:18 PM +03, Jason McBrayer wrote: > >> Which markers should we use? [...] We can use '_', but it's less used > >> (to imply underlines). I'm open to suggestions. > > > > Using '_' would also conflict with snake_cased_variables in various > > programming contexts, which would also require the addition of a "inline > > preformatted" marker, which probably would complicate this even more. > > Considering we have the full power of Unicode at our disposal -Thomas mentioned italicized math symbols previously- perhaps one could use some fancy combining diacritic ala "combining low line" at U+0332 to achieve the same effect: > > https://en.wikipedia.org/wiki/Underscore#Unicode > > My 2?: enough fidgeting with text/gemini. Let us try to use what we have in creative, forward looking ways ? It's ? 2020 ? we ? don't ? need ? italics ? to ? show ? emphasis.
On Thu, Nov 12, 2020 at 10:23 PM Michael Lazar <lazar.michael22 at gmail.com> wrote: It's ? 2020 ? we ? don't ? need ? italics ? to ? show ? emphasis. > ?. It'll be quite a bit later than 2020 before you see that kind of emphasis in textbooks or novels. John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org This great college [Trinity], of this ancient university [Cambridge], has seen some strange sights. It has seen Wordsworth drunk and Porson sober. And here am I, a better poet than Porson, and a better scholar than Wordsworth, somewhere betwixt and between. --A.E. Housman -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201112/c1b6 495d/attachment.htm>
It was thus said that the Great Michael Lazar once stated: > > It's ? 2020 ? we ? don't ? need ? italics ? to ? show ? emphasis. It took me two operating systems and three programs to see what unoly Unicode you were trying to unleash here. If you want styled text, you have options, but they are *NOT* text/gemini. Oh, sorry, ? NOT ? text/gemini. -spc (God, there are times when I absolutely hate Unicode, and this is one of them ... )
> On Nov 13, 2020, at 08:45, Sean Conner <sean at conman.org> wrote: > > -spc (God, there are times when I absolutely hate Unicode, and this is one > of them ... ) And yet... perhaps this is one area where gemini could make a difference... sane unicode support for the people! THE PEOPLE! Thanks for playing.
> However, I think it is a sign of stronger writing if an author is able
to convey their meaning without resorting to what's essentially metadata
in their text. Use syntax, word choice, and punctuation to express your intent!
This makes absolutely no sense.
What's the difference between regular letters and letters that have diacritics?
What's the difference between capitals and lowercase? What about Hebrew
Vowels? Are all those "metadata" also?
Italics conveys data itself.
Italics is part of the writing system. It's not "metadata"
It's literally no different from using punctuation, or capitals.
Christian Seibold
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
??????? Original Message ???????
On Monday, November 9th, 2020 at 6:31 PM, John Cowan <cowan at ccil.org> wrote:
> On Mon, Nov 9, 2020 at 6:46 PM Philip Linde <linde.philip at gmail.com> wrote:
>
>> The /italics/ style has the unfortunate side effect of producing false
>> positives for quite plausible Unix paths, e.g. /etc/.
>
> Such markup should really only be recognized if there is whitespace or
the beginning of the line before it and whitespace, the end of the line,
or sentence-ending punctuation after it. One advantage of _ is that it is
not normally used in running text.
>
>> This has never
>> been a problem in the settings I use this style of implying typography
>> (mostly IRC) because the input isn't typically transformed and is
>> presented as written
>
> There are IRC clients that interpret it.
> On Mon, Nov 9, 2020 at 6:52 PM acdw <acdw at acdw.net> wrote:
>
>> However, I think it is a sign of stronger writing if an author is able
to convey their meaning without resorting to what's essentially metadata
in their text. Use syntax, word choice, and punctuation to express your intent!
>
> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>
> 1) Titles of books, movies, magazines, and other stand-alone works.
>
> 2) Scientific names of plants and animals.
>
> 3) Terms being introduced for the first time.
>
> 4) In narrative, the thoughts of a character.
>
> 5) Words being used as examples of themselves. ("The word _the_ is a
definite article.")
>
> 6) Names of ships.
>
> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
> When I'm stuck in something boring where reading would be impossible or
> rude, I often set up math problems for myself and solve them as a way
> to pass the time. --John Jenkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/f49e
1da4/attachment-0001.htm>
To further what I'm saying. Italics often conveys emphasis,
which is conveyed in speech with intonation. Intonation is
data itself. Italics is one of the few methods we can convey
that in writing.
Italics can also convey other information. A new word, for example.
You do the same thing in speech. In speech when you introduce a new
word you might put extra emphasis on the word, slow down your speaking,
etc. This is also linguistic data.
Christian Seibold
Sent with [ProtonMail](https://protonmail.com/) Secure Email.
??????? Original Message ???????
On Thursday, November 26th, 2020 at 1:06 AM, Krixano <krixano at protonmail.com> wrote:
>> However, I think it is a sign of stronger writing if an author is able
to convey their meaning without resorting to what's essentially metadata
in their text. Use syntax, word choice, and punctuation to express your intent!
>
> This makes absolutely no sense.
> What's the difference between regular letters and letters that have diacritics?
> What's the difference between capitals and lowercase? What about Hebrew
> Vowels? Are all those "metadata" also?
> Italics conveys data itself.
> Italics is part of the writing system. It's not "metadata"
> It's literally no different from using punctuation, or capitals.
>
> Christian Seibold
>
> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>
> ??????? Original Message ???????
> On Monday, November 9th, 2020 at 6:31 PM, John Cowan <cowan at ccil.org> wrote:
>
>> On Mon, Nov 9, 2020 at 6:46 PM Philip Linde <linde.philip at gmail.com> wrote:
>>
>>> The /italics/ style has the unfortunate side effect of producing false
>>> positives for quite plausible Unix paths, e.g. /etc/.
>>
>> Such markup should really only be recognized if there is whitespace or
the beginning of the line before it and whitespace, the end of the line,
or sentence-ending punctuation after it. One advantage of _ is that it is
not normally used in running text.
>>
>>> This has never
>>> been a problem in the settings I use this style of implying typography
>>> (mostly IRC) because the input isn't typically transformed and is
>>> presented as written
>>
>> There are IRC clients that interpret it.
>> On Mon, Nov 9, 2020 at 6:52 PM acdw <acdw at acdw.net> wrote:
>>
>>> However, I think it is a sign of stronger writing if an author is able
to convey their meaning without resorting to what's essentially metadata
in their text. Use syntax, word choice, and punctuation to express your intent!
>>
>> Contexts where that doesn't work, from WP (and yes, I'm being pedantic):
>>
>> 1) Titles of books, movies, magazines, and other stand-alone works.
>>
>> 2) Scientific names of plants and animals.
>>
>> 3) Terms being introduced for the first time.
>>
>> 4) In narrative, the thoughts of a character.
>>
>> 5) Words being used as examples of themselves. ("The word _the_ is a
definite article.")
>>
>> 6) Names of ships.
>>
>> John Cowan http://vrici.lojban.org/~cowan cowan at ccil.org
>> When I'm stuck in something boring where reading would be impossible or
>> rude, I often set up math problems for myself and solve them as a way
>> to pass the time. --John Jenkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/9f98
baa3/attachment.htm>
Krixano <krixano at protonmail.com> wrote: > To further what I'm saying. Italics often conveys emphasis, > which is conveyed in speech with intonation. Intonation is > data itself. Italics is one of the few methods we can convey > that in writing. > Gemtext is limited similarly to typewriters in that they don't typically support italics. How did they express emphasis on typewriters? On the other hand, the output of typewriters wasn't meant to be accessible to screen readers. I have already listed a bunch of different ways to convey the same thing as you would with italics and their drawbacks. Sidenote: Since gemtext is UTF-8 by default and lack a way to suggest a custom font, you could probably extend UTF-8 in the range <U+F0000> to <U+10FFFF> for markup, like <U+F7777> for emphasis. I really don't like that idea, but you get away from clashing with snake_case and the like. -- Katarina -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201126/3e14 77a5/attachment.htm>
On 11/26/20 1:06 AM, Krixano wrote: >> However, I think it is a sign of stronger writing if an author is able to convey their meaning without resorting to what's essentially metadata in their text. Use syntax, word choice, and punctuation to express your intent! > > This makes absolutely no sense. > What's the difference between regular letters and letters that have diacritics? A phonemic distinction -- a diacritic'd letter vs. a plain letter can differentiate words. The same is not true of italics, which are typographic in nature. > What's the difference between capitals and lowercase? This point is more warranted, I think. After all, a lot of scripts don't differentiate between capitals and minuscules at all, and in fact the Roman alphabet didn't have it for much of its history. However, the distinction is already "supported" in ASCII/UTF, which is why I suggested its use in lieu of the poorly-supported italic convention. Use the tools we have, and all that. > What about Hebrew > Vowels? Are all those "metadata" also? I don't know enough about Hebrew to comment, but I would think it'd fall under my previous paragraph. > Italics conveys data itself. > Italics is part of the writing system. It's not "metadata" > It's literally no different from using punctuation, or capitals. The thing is -- if we were to include italics in the spec for text/gemini, it'd be set off *using* punctuation, a la Markdown or BBText or even HTML. So why not just use that naked punctuation? I think it's just as easy to understand that *this* is italic as if it were actually *in* italics. -- ~acdw (Case) www.acdw.net | breadpunk.club/~breadw
On 2020-11-26 13:19, Katarina Eriksson wrote: > Gemtext is limited similarly to typewriters in that they don't > typically support italics. How did they express emphasis on > typewriters? On the other hand, the output of typewriters wasn't meant > to be accessible to screen readers. > > I have already listed a bunch of different ways to convey the same > thing as you would with italics and their drawbacks. This Nov 10 post contains a fine list, mentioning capitalization, all-uppercase, letter-spacing, extra space/newline around word/sentence ? similar ideas as listed in Wikipedia on methods of typographic emphasis: https://en.wikipedia.org/wiki/Emphasis_(typography)#Methods_and_use I wouldn't mind clients opting for a distinctive rendering like e. g. Thunderbird's so-called Structured Text in plain text e-mail, which suggests *bold* and /italic/ and _underlined_ text ? optionally (mail.display_struct, default:true) rendered bold/italic/underlined, but without deleting any chars as I experience it. Jargon File "Hacker Writing Style" is mentionend following a ref there: http://kb.mozillazine.org/Plain_text_e-mail_%28Thunderbird%29#Structured_Text http://kb.mozillazine.org/Mail_and_news_settings ? mail.display_struct
---