I am still getting used to the new method for reading and posting
messages, and I have been curious about what the capabilities are, since
I know that what I see in a posting may not necessarily be the same as
what others see, especially with regard to spacing and the use of
special characters. Also, in the past, the "archives" (such as they
still exist at all) have often taken such extreme liberties with some of
the carefully prepared tables which I have composed in the past (such as
removing all of the careful spacing) that many of these tables now look
like gibberish in whatever survives of them. So, I have composed a
short genealogy of that part of the Mamikonid family (including the key
Gregorid marriage) which is documented by one of the most reliable of
the early Armenian historians, Lazar Parapeci, a life-long friend of the
Vahan Mamikonean who appears in the tables below. To my knowledge, no
reasonably early source provides documentation for either the parentage
of Hamazasp or for any genealogical connection of this extended family
group with any other Mamikonids (although descent from Vard seems more
likely than not). The two tables are intended to have exactly the same
information, but in two different formats to show the advantages and
disadvantages of each. The first table (more tedious to compose) is of
the more traditional type, but needs a constant-width font and a
line-length of at least 70 characters to display correctly (and more
importantly, any "archive which messes with the spacing is likely to
make the table unintelligible). The second one, which also needs a line
length of 70 characters or so, might be more resistant to meddling of
the type done by any "archiving" method.

As another test, I have used a handful of characters with diacritical
markings which may not display correctly if Unicode is not adequately
supported.

Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
of the Mamikonids | katholikos of the Armenians
________________________________|_____________________________
|                                | |
Vardan, d. 451 Hmayeak, d. 451 Hamazaspean
'sparapet' m. Juik Arcruni
| __________________|____________________________
| |                            | | |
daughter m. Vahan 'mets', d. ca. 510, Vasak Artašēs Vard,
Aršawir 'marzpan' of Armenia, d. 482 d. ca.
Kamsarakan 485 - ca. 510 general 515?,
| 'marzpan'
Grigor, of
fl. 485 Armenia

Hamazasp, lord (tēr) of the Mamikonids,
m. Sahakanuš, daughter of Sahak (Isaac), katholikos of the Armenians
|
|——Vardan, d. 451, 'sparapet'
| |
| |——daughter m. Aršawir Kamsarakan
|
|——Hmayeak, d. 451, m. Juik Arcruni
| |
| |——Vahan 'mets', d. ca. 510, 'marzpan' of Armenia, 485 - ca. 510
| |
| |——Vasak, d. 482, general of Armenia
| | |
| | |--Grigor, fl. 485
| |
| |——Artašēs
| |
| |——Vard, d. ca. 515?, 'marzpan' of Armenia
|
|——Hamazaspean

As a more ambitious test, the following, if it displays correctly,
should show how the names in the above table look in the Armenian alphabet.

Artašēs [Artashes] = Արտաշէս
Aršawir [Arshavir] = Արշաւիր
Grigor = Գրիգոր
Hamazasp = Համազասպ
Hamazaspean = Համազասպեան
Hmayeak = Հմայեակ
Sahak = Սահակ
Sahakanuš [Sahakanush] = Սահականուշ
Vahan = Վահան
Vard = Վարդ
Vardan = Վարդան
Vasak = Վասակ

Kamsarakan = Կամսարական
Mamikonean = Մամիկոնեան

Comments on which of the formats is best are welcome.

Stewart Baldwin

On 3/8/2024 3:40 PM, Stewart Baldwin wrote:

> As another test, I have used a handful of characters with diacritical
> markings which may not display correctly if Unicode is not adequately
> supported.
>
>                Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
>                of the Mamikonids    | katholikos of the Armenians
>     ________________________________|_____________________________
>    |                                |                             |
> Vardan, d. 451                   Hmayeak, d. 451             Hamazaspean
> 'sparapet'                       m. Juik Arcruni
>    |              __________________|____________________________
>    |             |                            |          |       |
> daughter m.    Vahan 'mets', d. ca. 510,    Vasak    Artašēs   Vard,
> Aršawir        'marzpan' of Armenia,        d. 482             d. ca.
> Kamsarakan     485 - ca. 510                general            515?,
>                                               |                'marzpan'
>                                             Grigor,            of
>                                             fl. 485            Armenia

I am seeing layout and diacriticals as I presume you intended them. Some
more tests:

موسى بن موسى القسويو

Íñigo Fórtunez

Æðelred of the Geƿesse

taf

On 08/03/2024 23:40, Stewart Baldwin wrote:
> I am still getting used to the new method for reading and posting
> messages, and I have been curious about what the capabilities are, since
> I know that what I see in a posting may not necessarily be the same as
> what others see, especially with regard to spacing and the use of
> special characters.  Also, in the past, the "archives" (such as they
> still exist at all) have often taken such extreme liberties with some of
> the carefully prepared tables which I have composed in the past (such as
> removing all of the careful spacing) that many of these tables now look
> like gibberish in whatever survives of them.  So, I have composed a
> short genealogy of that part of the Mamikonid family (including the key
> Gregorid marriage) which is documented by one of the most reliable of
> the early Armenian historians, Lazar Parapeci, a life-long friend of the
> Vahan Mamikonean who appears in the tables below.  To my knowledge, no
> reasonably early source provides documentation for either the parentage
> of Hamazasp or for any genealogical connection of this extended family
> group with any other Mamikonids (although descent from Vard seems more
> likely than not).  The two tables are intended to have exactly the same
> information, but in two different formats to show the advantages and
> disadvantages of each.  The first table (more tedious to compose) is of
> the more traditional type, but needs a constant-width font and a
> line-length of at least 70 characters to display correctly (and more
> importantly, any "archive which messes with the spacing is likely to
> make the table unintelligible).  The second one, which also needs a line
> length of 70 characters or so, might be more resistant to meddling of
> the type done by any "archiving" method.
>
> As another test, I have used a handful of characters with diacritical
> markings which may not display correctly if Unicode is not adequately
> supported.
>
>                Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
>                of the Mamikonids    | katholikos of the Armenians
>     ________________________________|_____________________________
>    |                                |                             |
> Vardan, d. 451                   Hmayeak, d. 451             Hamazaspean
> 'sparapet'                       m. Juik Arcruni
>    |              __________________|____________________________
>    |             |                            |          |       |
> daughter m.    Vahan 'mets', d. ca. 510,    Vasak    Artašēs   Vard,
> Aršawir        'marzpan' of Armenia,        d. 482             d. ca.
> Kamsarakan     485 - ca. 510                general            515?,
>                                               |                'marzpan'
>                                             Grigor,            of
>                                             fl. 485            Armenia
>
>
> Hamazasp, lord (tēr) of the Mamikonids,
> m. Sahakanuš, daughter of Sahak (Isaac), katholikos of the Armenians
>   |
>   |——Vardan, d. 451, 'sparapet'
>   |    |
>   |    |——daughter m. Aršawir Kamsarakan
>   |
>   |——Hmayeak, d. 451, m. Juik Arcruni
>   |    |
>   |    |——Vahan 'mets', d. ca. 510, 'marzpan' of Armenia, 485 - ca. 510
>   |    |
>   |    |——Vasak, d. 482, general of Armenia
>   |    |    |
>   |    |    |--Grigor, fl. 485
>   |    |
>   |    |——Artašēs
>   |    |
>   |    |——Vard, d. ca. 515?, 'marzpan' of Armenia
>   |
>   |——Hamazaspean
>
> As a more ambitious test, the following, if it displays correctly,
> should show how the names in the above table look in the Armenian alphabet.
>
> Artašēs [Artashes] = Արտաշէս
> Aršawir [Arshavir] = Արշաւիր
> Grigor = Գրիգոր
> Hamazasp = Համազասպ
> Hamazaspean = Համազասպեան
> Hmayeak = Հմայեակ
> Sahak = Սահակ
> Sahakanuš [Sahakanush] = Սահականուշ
> Vahan = Վահան
> Vard = Վարդ
> Vardan = Վարդան
> Vasak = Վասակ
>
> Kamsarakan = Կամսարական
> Mamikonean = Մամիկոնեան
>
> Comments on which of the formats is best are welcome.
>
> Stewart Baldwin

I think many of us are having to get used to unfamiliar layouts now. I'm
following the group on both Thunderbird, where your layout and scripts
look fine, and also Narkive where it is messed up. This is my first time
replying to a post via Thunderbird, so fingers crossed. David

Looks OK on SeaNonkey (descendent of the old Netscape Navigator).

However, I've often wondered whether .svg files could be included in
posts. At least one genealogy program will generate SVG and suspect
most of them do. At least one diagram drawing application, Dia, will
also generate SVG.

SVG is text (technically it's XML which is text) so if the lines are
wrapped to restrict line lengths it ought to be possible to paste it in
line and on receipt copy and paste into a text file with a .svg suffix
to view with whatever vector graphics program is on your PC (Inkscape is
pretty standard on Linux but inkscape.org has downloads for Windows and
MacOS).

SVGZ is binary. It's compressed SVG so would have to be unzipped to get
a text file but is otherwise equivalent.

I'll run a test, cros-sposting to s.g.computing.

Ian

On 3/9/2024 1:28 AM, David Topping wrote:

> I think many of us are having to get used to unfamiliar layouts now. I'm
> following the group on both Thunderbird, where your layout and scripts
> look fine, and also Narkive where it is messed up. This is my first time
> replying to a post via Thunderbird, so fingers crossed. David

I don't know how to fix this. To get charts to appear properly, they
must be constructed and displayed using a non-proportional font, giving
each letter or graphical element the same horizontal space. Thunderbird
defaults to this for Usenet. Narkive unfortunately uses proportional
font, adjusting character width. I looked in two different browsers and
did not find a way to specify a switch to a different font only for
specific pages, just global overrides, and that would effect all web
sites you view, potentially breaking some of them.

The best approach is probably to copy the chart and paste it into
Notepad, Word or any text package that lets you adjust font size, and
change the font to a non-proportional one.

taf

Some other things to think about:

1. Will anyone be archiving future messages now that Google has quit
supporting Usenet?

2. When will Google quit making archives of old messages available? (I
figure that it is only a matter of time before the bean-counters make
that decision.)

3. If somebody does decide to archive messages, will the messages be
archived faithfully, or will the decision-makers decide that all of
those special characters, accents, and carefully planned spacing are
just getting in the way of doing things cheaply?

Stewart Baldwin

On 3/15/2024 9:33 PM, Stewart Baldwin wrote:
> Some other things to think about:
>
> 1. Will anyone be archiving future messages now that Google has quit
> supporting Usenet?

Narkive is still archiving.

https://soc.genealogy.medieval.narkive.com/

(According to their home page, they are even open to integrating old
Usenet archives that anyone might have saved.)

> 2. When will Google quit making archives of old messages available?  (I
> figure that it is only a matter of time before the bean-counters make
> that decision.)

The key is how long Google Groups is viewed as viable. The size of the
whole Usenet archive pales in comparison to their other data, so it is
not a priority target for bean-counters. However, it will be if they
decide Google Groups as a whole is not worth maintaining, with the
Usenet archive being collateral damage of such a decision.

> 3. If somebody does decide to archive messages, will the messages be
> archived faithfully, or will the decision-makers decide that all of
> those special characters, accents, and carefully planned spacing are
> just getting in the way of doing things cheaply?

Yes, and no. In terms of the special characters, as long as they are
standard unicode encoded, it shouldn't be an issue. All of the
characters used in this thread - Armenian, Arabic, Old English, etc.,
are showing up in Narkive exactly as they appeared here. Not so with the
spacing/charts.

They are not coming through true and it is irreparable. There are two
separate issues. First, Narkive is using a proportional font. This can
be repaired using browser addons like Stylish, which lets you
permanently override the native font for specified pages (but isn't easy
to use), or if you are using the right browser, the Google Font
Previewer for Chrome, which lets you preview a web page using a
different (in this case non-proportional) font.

However, Narkive is also apparently deleting most 'repetitive' spacing,
so the proportional/non-proportional font switch does not repair the
problem. This is an irrecoverable fault - there is nothing that can be
done to restore the original formatting.

There may be ugly and inconvenient workarounds. The following is a test.
We will see how it shows up on Narkive.

................Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
................of the Mamikonids....| katholikos of the Armenians
.....________________________________|_____________________________
....|................................|.............................|
Vardan, d. 451...................Hmayeak, d. 451.............Hamazaspean
'sparapet'.......................m. Juik Arcruni
.. .|. . . . . . . __________________|____________________________
.. .|. . . . . . .|. . . . . . . . . . . . . . |. . . . .|. . . . |
daughter m. . .Vahan 'mets', d. ca. 510, . .Vasak . .Artašēs . Vard,
Aršawir . . . .'marzpan' of Armenia, . . . .d. 482 . . . . . . d. ca.
Kamsarakan . . 485 - ca. 510 . . . . . . . .general . . . . . .515?,
.. . . . . . . . . . . . . . . . . . . . . . . | . . . . . . . .'marzpan'
.. . . . . . . . . . . . . . . . . . . . . . Grigor, . . . . . .of
.. . . . . . . . . . . . . . . . . . . . . . fl. 485 . . . . . .Armenia

taf

On 3/16/2024 11:10 PM, taf wrote:
> There may be ugly and inconvenient workarounds. The following is a test.
> We will see how it shows up on Narkive.
>
> ...............Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
> ...............of the Mamikonids....| katholikos of the Armenians
> ....________________________________|_____________________________
> ...|................................|.............................|
> Vardan, d. 451...................Hmayeak, d. 451.............Hamazaspean
> 'sparapet'.......................m. Juik Arcruni
> . .|. . . . . . . __________________|____________________________
> . .|. . . . . . .|. . . . . . . . . . . . . . |. . . . .|. . . . |
> daughter m. . .Vahan 'mets', d. ca. 510, . .Vasak . .Artašēs . Vard,
> Aršawir . . . .'marzpan' of Armenia, . . . .d. 482 . . . . . . d. ca.
> Kamsarakan . . 485 - ca. 510 . . . . . . . .general . . . . . .515?,
> . . . . . . . . . . . . . . . . . . . . . . . | . . . . . . . .'marzpan'
> . . . . . . . . . . . . . . . . . . . . . . Grigor, . . . . . .of
> . . . . . . . . . . . . . . . . . . . . . . fl. 485 . . . . . .Armenia

Good news: The use of dots (with or without intervening spaces) solved
the problem of Narkive removing repetitive spacing - you still have to
switch to a non-proportional (monospace) font to view, but the spacing
is retained correctly. However, . . .

Bad news: Their display enforces indenting for followup posts, which
ended up screen-wrapping the right-most material in the chart onto the
next line. This means that even using dots to post and reading with a
font-switching add-on like I mentioned, it won't display properly if it
is too far down the response tree (looks to be a 5-character indent per
response level, so this chart in a 4th-level response would have needed
to be 20 characters narrower).

To see it as intended, I had to copy it from Narkive into Notepad, where
it presented properly with no manipulation (Notepad apparently defaults
to monospace Courier). And since no novice reader is going to know to do
this, If one wants to present a chart that can be properly read on
Narkive, it might be best to include a statement like 'if chart is not
displaying properly, copy and paste chart into Notepad or other text
program allowing viewing with Courier font'. This is far from ideal, and
not actually new - Google Groups messed up charts too - but it is what
we are left with, it seems.

taf

On 3/17/2024 1:45 PM, taf wrote:
> On 3/16/2024 11:10 PM, taf wrote:
>> There may be ugly and inconvenient workarounds. The following is a
>> test. We will see how it shows up on Narkive.
>>
>> ...............Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
>> ...............of the Mamikonids....| katholikos of the Armenians
>> ....________________________________|_____________________________
>> ...|................................|.............................|
>> Vardan, d. 451...................Hmayeak, d. 451.............Hamazaspean
>> 'sparapet'.......................m. Juik Arcruni
>> . .|. . . . . . . __________________|____________________________
>> . .|. . . . . . .|. . . . . . . . . . . . . . |. . . . .|. . . . |
>> daughter m. . .Vahan 'mets', d. ca. 510, . .Vasak . .Artašēs . Vard,
>> Aršawir . . . .'marzpan' of Armenia, . . . .d. 482 . . . . . . d. ca.
>> Kamsarakan . . 485 - ca. 510 . . . . . . . .general . . . . . .515?,
>> . . . . . . . . . . . . . . . . . . . . . . . | . . . . . . . .'marzpan'
>> . . . . . . . . . . . . . . . . . . . . . . Grigor, . . . . . .of
>> . . . . . . . . . . . . . . . . . . . . . . fl. 485 . . . . . .Armenia
>
> Good news: The use of dots (with or without intervening spaces) solved
> the problem of Narkive removing repetitive spacing - you still have to
> switch to a non-proportional (monospace) font to view, but the spacing
> is retained correctly. However, . . .
>
> Bad news: Their display enforces indenting for followup posts, which
> ended up screen-wrapping the right-most material in the chart onto the
> next line. This means that even using dots to post and reading with a
> font-switching add-on like I mentioned, it won't display properly if it
> is too far down the response tree (looks to be a 5-character indent per
> response level, so this chart in a 4th-level response would have needed
> to be 20 characters narrower).
>
> To see it as intended, I had to copy it from Narkive into Notepad, where
> it presented properly with no manipulation (Notepad apparently defaults
> to monospace Courier). And since no novice reader is going to know to do
> this, If one wants to present a chart that can be properly read on
> Narkive, it might be best to include a statement like 'if chart is not
> displaying properly, copy and paste chart into Notepad or other text
> program allowing viewing with Courier font'. This is far from ideal, and
> not actually new - Google Groups messed up charts too - but it is what
> we are left with, it seems.
>
> taf
How about posting the appropriate gedcom information. Then viewers could
just copy the gedcom text into a file and open it in a gedcom viewer.

> On 3/17/2024 1:45 PM, taf wrote:
>> On 3/16/2024 11:10 PM, taf wrote:
>>> There may be ugly and inconvenient workarounds. The following is a
>>> test. We will see how it shows up on Narkive.
>>>
>>> ...............Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
>>> ...............of the Mamikonids....| katholikos of the Armenians
>>> ....________________________________|_____________________________
>>> ...|................................|.............................|
>>> Vardan, d. 451...................Hmayeak, d.
451.............Hamazaspean
>>> 'sparapet'.......................m. Juik Arcruni
>>> . .|. . . . . . . __________________|____________________________
>>> . .|. . . . . . .|. . . . . . . . . . . . . . |. . . . .|. . . . |
>>> daughter m. . .Vahan 'mets', d. ca. 510, . .Vasak . .Artašēs . Vard,
>>> Aršawir . . . .'marzpan' of Armenia, . . . .d. 482 . . . . . . d. ca.
>>> Kamsarakan . . 485 - ca. 510 . . . . . . . .general . . . . . .515?,
>>> . . . . . . . . . . . . . . . . . . . . . . . | . . . . . . .
..'marzpan'
>>> . . . . . . . . . . . . . . . . . . . . . . Grigor, . . . . . .of
>>> . . . . . . . . . . . . . . . . . . . . . . fl. 485 . . . . . .Armenia
>>

>> To see it as intended, I had to copy it from Narkive into Notepad,
>> where it presented properly with no manipulation (Notepad apparently
>> defaults to monospace Courier). And since no novice reader is going to
>> know to do this, If one wants to present a chart that can be properly
>> read on Narkive, it might be best to include a statement like 'if
>> chart is not displaying properly, copy and paste chart into Notepad or
>> other text program allowing viewing with Courier font'. This is far
>> from ideal, and not actually new - Google Groups messed up charts too
>> - but it is what we are left with, it seems.
>>
> How about posting the appropriate gedcom information. Then viewers could
> just copy the gedcom text into a file and open it in a gedcom viewer.

A chart like the one above is directly viewable in the original Usenet
post, and for the Narkive work-around, everyone has some form of text
reader. From my perspective, that compares favorably to GEDCOM data,
meaningless without loading the code into specialty software that many
novices (and some not-so-novices) may not have.

taf

On 18-Mar-24 9:27 AM, taf wrote:
> > On 3/17/2024 1:45 PM, taf wrote:
> >> On 3/16/2024 11:10 PM, taf wrote:
> >>> There may be ugly and inconvenient workarounds. The following is a
> >>> test. We will see how it shows up on Narkive.
> >>>
> >>> ...............Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
> >>> ...............of the Mamikonids....| katholikos of the Armenians
> >>> ....________________________________|_____________________________
> >>> ...|................................|.............................|
> >>> Vardan, d. 451...................Hmayeak, d.
> 451.............Hamazaspean
> >>> 'sparapet'.......................m. Juik Arcruni
> >>> . .|. . . . . . . __________________|____________________________
> >>> . .|. . . . . . .|. . . . . . . . . . . . . . |. . . . .|. . . . |
> >>> daughter m. . .Vahan 'mets', d. ca. 510, . .Vasak . .Artašēs . Vard,
> >>> Aršawir . . . .'marzpan' of Armenia, . . . .d. 482 . . . . . . d. ca.
> >>> Kamsarakan . . 485 - ca. 510 . . . . . . . .general . . . . . .515?,
> >>> . . . . . . . . . . . . . . . . . . . . . . . | . . . . . . .
> .'marzpan'
> >>> . . . . . . . . . . . . . . . . . . . . . . Grigor, . . . . . .of
> >>> . . . . . . . . . . . . . . . . . . . . . . fl. 485 . . . . . .Armenia
> >>
>
> >> To see it as intended, I had to copy it from Narkive into Notepad,
> >> where it presented properly with no manipulation (Notepad apparently
> >> defaults to monospace Courier). And since no novice reader is going to
> >> know to do this, If one wants to present a chart that can be properly
> >> read on Narkive, it might be best to include a statement like 'if
> >> chart is not displaying properly, copy and paste chart into Notepad or
> >> other text program allowing viewing with Courier font'. This is far
> >> from ideal, and not actually new - Google Groups messed up charts too
> >> - but it is what we are left with, it seems.
> >>
> > How about posting the appropriate gedcom information. Then viewers could
> > just copy the gedcom text into a file and open it in a gedcom viewer.
>
> A chart like the one above is directly viewable in the original Usenet
> post, and for the Narkive work-around, everyone has some form of text
> reader. From my perspective, that compares favorably to GEDCOM data,
> meaningless without loading the code into specialty software that many
> novices (and some not-so-novices) may not have.

Some IT dummies, like myself, won't even know what gedcom means.

Peter Stewart

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

On 3/17/2024 1:10 AM, taf wrote:
> On 3/15/2024 9:33 PM, Stewart Baldwin wrote:
>> Some other things to think about:
>>
>> 1. Will anyone be archiving future messages now that Google has quit
>> supporting Usenet?
>
> Narkive is still archiving.
>
> https://soc.genealogy.medieval.narkive.com/
>
> (According to their home page, they are even open to integrating old
> Usenet archives that anyone might have saved.)
>
>> 2. When will Google quit making archives of old messages available?
>> (I figure that it is only a matter of time before the bean-counters
>> make that decision.)
>
> The key is how long Google Groups is viewed as viable. The size of the
> whole Usenet archive pales in comparison to their other data, so it is
> not a priority target for bean-counters. However, it will be if they
> decide Google Groups as a whole is not worth maintaining, with the
> Usenet archive being collateral damage of such a decision.

I guess the same question could be asked of Narkive. How long can we
count on it being around?

>> 3. If somebody does decide to archive messages, will the messages be
>> archived faithfully, or will the decision-makers decide that all of
>> those special characters, accents, and carefully planned spacing are
>> just getting in the way of doing things cheaply?
>
> Yes, and no. In terms of the special characters, as long as they are
> standard unicode encoded, it shouldn't be an issue. All of the
> characters used in this thread - Armenian, Arabic, Old English, etc.,
> are showing up in Narkive exactly as they appeared here. Not so with the
> spacing/charts.
>
> They are not coming through true and it is irreparable. There are two
> separate issues. First, Narkive is using a proportional font. This can
> be repaired using browser addons like Stylish, which lets you
> permanently override the native font for specified pages (but isn't easy
> to use), or if you are using the right browser, the Google Font
> Previewer for Chrome, which lets you preview a web page using a
> different (in this case non-proportional) font.
>
> However, Narkive is also apparently deleting most 'repetitive' spacing,
> so the proportional/non-proportional font switch does not repair the
> problem. This is an irrecoverable fault - there is nothing that can be
> done to restore the original formatting.
>
>
> There may be ugly and inconvenient workarounds. The following is a test.
> We will see how it shows up on Narkive.
>
> ...............Hamazasp, lord (tēr) = Sahakanuš, daughter of Sahak,
> ...............of the Mamikonids....| katholikos of the Armenians
> ....________________________________|_____________________________
> ...|................................|.............................|
> Vardan, d. 451...................Hmayeak, d. 451.............Hamazaspean
> 'sparapet'.......................m. Juik Arcruni
> . .|. . . . . . . __________________|____________________________
> . .|. . . . . . .|. . . . . . . . . . . . . . |. . . . .|. . . . |
> daughter m. . .Vahan 'mets', d. ca. 510, . .Vasak . .Artašēs . Vard,
> Aršawir . . . .'marzpan' of Armenia, . . . .d. 482 . . . . . . d. ca.
> Kamsarakan . . 485 - ca. 510 . . . . . . . .general . . . . . .515?,
> . . . . . . . . . . . . . . . . . . . . . . . | . . . . . . . .'marzpan'
> . . . . . . . . . . . . . . . . . . . . . . Grigor, . . . . . .of
> . . . . . . . . . . . . . . . . . . . . . . fl. 485 . . . . . .Armenia
>
> taf

This reminded me of an additional test which I already performed in my
original posting, but forgot to mention (and forgot to check until your
posting reminded me). If you look at my original posting in this thread
as it appears at Narkive, most appearances of the "|" symbol twice or
more on the same line which had many spaces between them in my original
posting were archived by Narkive having only one space between them, but
notice that there are two places where the original spacing between two
|'s was maintained. That is because in those two place the occurrence
of many consecutive spaces actually alternated between "ordinary" (ASCii
32) spaces and "non-breaking" (ASCii 160) spaces, as an experiment to
see if non-breaking spaces made a difference. My experiment appears to
have worked, although the effect would be hard to notice on my original
posting until I told you about it (or unless you did a search for a
single space character and found that you were only hitting every other
one).

Here is a similar test. Each line starts with 20 spaces of the type
indicated.

Twenty regular spaces to the left on this line
Twenty non-breaking spaces to the left on this line
Ten each (alternating) on this line.

In Thunderbird, there should be no difference in the amount of space to
the left in these three lines. In Narkive, if things go as before,
there should be only one space showing at the beginning of the first
test line and twenty spaces beginning the third test line. It remains
to be seen whether or not consecutive non-breaking spaces get collapsed
into a single space by Narkive in the same way that ordinary spaces do.

Stewart Baldwin

On 3/18/2024 8:49 AM, Stewart Baldwin wrote:
> On 3/17/2024 1:10 AM, taf wrote:
>> On 3/15/2024 9:33 PM, Stewart Baldwin wrote:
>>> 1. Will anyone be archiving future messages now that Google has quit
>>> supporting Usenet?

>>> 2. When will Google quit making archives of old messages available?
>>> (I figure that it is only a matter of time before the bean-counters
>>> make that decision.)
>>
>> The key is how long Google Groups is viewed as viable. The size of the
>> whole Usenet archive pales in comparison to their other data, so it is
>> not a priority target for bean-counters. However, it will be if they
>> decide Google Groups as a whole is not worth maintaining, with the
>> Usenet archive being collateral damage of such a decision.
>
> I guess the same question could be asked of Narkive.  How long can we
> count on it being around?

Indeed. I don't think we can.

> This reminded me of an additional test which I already performed in my
> original posting, but forgot to mention (and forgot to check until your
> posting reminded me).  If you look at my original posting in this thread
> as it appears at Narkive, most appearances of the "|" symbol twice or
> more on the same line which had many spaces between them in my original
> posting were archived by Narkive having only one space between them, but
> notice that there are two places where the original spacing between two
> |'s was maintained.  That is because in those two place the occurrence
> of many consecutive spaces actually alternated between "ordinary" (ASCii
> 32) spaces and "non-breaking" (ASCii 160) spaces, as an experiment to
> see if non-breaking spaces made a difference.  My experiment appears to
> have worked, although the effect would be hard to notice on my original
> posting until I told you about it (or unless you did a search for a
> single space character and found that you were only hitting every other
> one).

I noticed that in some cases the spacing was maintained, and thought you
might have been using an alternative space character, but went down the
rabbit hole of fonts and forgot to investigate further.

> Here is a similar test.  Each line starts with 20 spaces of the type
> indicated.
>
>                     Twenty regular spaces to the left on this line
>                     Twenty non-breaking spaces to the left on this line
>                     Ten each (alternating) on this line.
>

Well, that was a failure. In each case, Narkive reported the same thing:

Twenty regular spaces to the left on this line
Twenty non-breaking spaces to the left on this line
Ten each (alternating) on this line.

No introductory spacing for any of them. I suspect any space, of either
type, before the first 'content' character is disregarded. Let's see:

.. Ten regular spaces to the left on this line
.. Ten non-breaking spaces to the left on this line
.. Five each (alternating) on this line.

taf

On 3/18/2024 1:27 PM, taf wrote:

> No introductory spacing for any of them. I suspect any space, of either
> type, before the first 'content' character is disregarded. Let's see:
>
> .            Ten regular spaces to the left on this line
> .            Ten non-breaking spaces to the left on this line
> .            Five each (alternating) on this line.

That didn't work either. Curiously the quoted version of Stewart's text
(with a '>' at the beginning) retained the spaces in all three forms,
but his with no initial character and mine with an initial '.' did not.

* x
| x
> x
! x
< x
: x
* x
& x
.. x
x

All these are with the copy-pasted alternating version.

taf

On 3/18/2024 1:53 PM, taf wrote:
> On 3/18/2024 1:27 PM, taf wrote:
>
>> No introductory spacing for any of them. I suspect any space, of
>> either type, before the first 'content' character is disregarded.
>> Let's see:
>>
>> .            Ten regular spaces to the left on this line
>> .            Ten non-breaking spaces to the left on this line
>> .            Five each (alternating) on this line.
>
>
> That didn't work either. Curiously the quoted version of Stewart's text
> (with a '>' at the beginning) retained the spaces in all three forms,
> but his with no initial character and mine with an initial '.' did not.
>
> *            x
> |            x
> >            x
> !            x
> <            x
> :            x
> *            x
> &            x
> .            x
>              x
>
> All these are with the copy-pasted alternating version.
>
> taf

| |test T
| |test N

taf

| |test

taf

On 3/18/2024 2:08 PM, taf wrote:
> |                    |test
>
> taf

OK, I can't even replicate Stewart's original outcome.

Stewart Baldwin wrote:
> Some other things to think about:
>
> 1. Will anyone be archiving future messages now that Google has quit
> supporting Usenet?

The server operators look on it as "retention" rather than "archiving".
I don't know how far back EternalSeptember and Individual.net go but
Giganews variously claims "18+" and "over 20" years of text retention.
They are a bit dearer than the others for individual subscriptions.

I use Giganews because my ISP, PlusNet, bundles it with the rest of the
subscription so have no experience of dealing with them directly.

A Usenet feed isn't directly searchable in the same way that an archive
is & I haven't tried filtering to see how far back I could actually go
without downloading vast amounts and searching it locally.

> 2. When will Google quit making archives of old messages available?  (I
> figure that it is only a matter of time before the bean-counters make
> that decision.)

This is a real concern.

> 3. If somebody does decide to archive messages, will the messages be
> archived faithfully, or will the decision-makers decide that all of
> those special characters, accents, and carefully planned spacing are
> just getting in the way of doing things cheaply?

Retained posts from any server should be unchanged.

As for Narkive I see my post of an SVG image is unchanged on copying.
However I noticed that Giganews peering agreements (how they exchange
with other servers) limits posts to 100k and the image of the small Kaye
tree, at over 90k, was pushing that. SVG images may not be the answer,
therefore.

I examined the original .dia file. If saved as uncompressed SVG it was
only 1/3 of that. Posting a .dia as SVG may be an alternative way of
communicating trees. It's a smaller file than an image and it has
shorter line lengths, something I was concerned about.

It might be worth investigating Dia if you aren't familiar with it. It
can be installed from the Windows store but I gather use on macOS is a
bit more difficult. At the very least it's worth looking at as a nice
means of drawing diagrams in general even if you never post the results.

Ian

Op 19-03-2024 om 20:01 schreef Ian Goddard:

> I examined the original .dia file.  If saved as uncompressed SVG it was
> only 1/3 of that.  Posting a .dia as SVG may be an alternative way of
> communicating trees.  It's a smaller file than an image and it has
> shorter line lengths, something I was concerned about.

I don't think it is, because many news servers simply reject messages
with attachments, and trying to get around that by pasting encoded
binaries in a non standard way may lead to counter measures too.

Enno Borgsteede wrote:
> Op 19-03-2024 om 20:01 schreef Ian Goddard:
>
>> I examined the original .dia file.  If saved as uncompressed SVG it
>> was only 1/3 of that.  Posting a .dia as SVG may be an alternative way
>> of communicating trees.  It's a smaller file than an image and it has
>> shorter line lengths, something I was concerned about.
>
> I don't think it is, because many news servers simply reject messages
> with attachments, and trying to get around that by pasting encoded
> binaries in a non standard way may lead to counter measures too.
>
>
The uncompressed files, like SVG files, are XML and XML is text. You
can put it in line. All you have to do is save everything form the line
that says <?xml version="1.0" encoding="UTF-8"?> to the one that says
</dia:diagram> inclusive as a file with a .dia suffix and that's it.

Ian

Stewart Baldwin wrote:

> Some other things to think about:

> 1. Will anyone be archiving future messages now that Google has quit
> supporting Usenet?

> 2. When will Google quit making archives of old messages available? (I
> figure that it is only a matter of time before the bean-counters make
> that decision.)

> 3. If somebody does decide to archive messages, will the messages be
> archived faithfully, or will the decision-makers decide that all of
> those special characters, accents, and carefully planned spacing are
> just getting in the way of doing things cheaply?

> Stewart Baldwin

Yes all 3 are a concern. I think the only real solution would be if
someone sponsors an institution like a university or research project
to archive them all properly, maybe google could sponsor this to
take the whole thing off their hands. Then it could be made available to
the academic community and the public alike like jstor etc. Aside from
the chap at narkive [who says he started archiving in 2009 when he was
17!] there is another at

https://www.usenetarchives.com/
https://www.usenetarchives.com/threads.php?id=soc.genealogy.medieval&y=0&r=0&p=1

but its clearly not complete [4 yrs old] and for sgm only covers
1996-2022, and probably not complete even between those parameters.
Plus the format seems a bit crude and you can only search the whole
archive not individual groups it seems. Whether the originator has
got bored and given up in 2022 i dunno.

mike

Op 20-03-2024 om 00:12 schreef Ian Goddard:

> The uncompressed files, like SVG files, are XML and XML is text.  You
> can put it in line.  All you have to do is save everything form the line
> that says <?xml version="1.0" encoding="UTF-8"?> to the one that says
> </dia:diagram> inclusive as a file with a .dia suffix and that's it.

I know that, but an attachment is sent as text too, so there really
isn't much of a difference. News servers may still reject them, because
they're not plain readable text.

Enno Borgsteede wrote:
> Op 20-03-2024 om 00:12 schreef Ian Goddard:
>
>> The uncompressed files, like SVG files, are XML and XML is text.  You
>> can put it in line.  All you have to do is save everything form the
>> line that says <?xml version="1.0" encoding="UTF-8"?> to the one that
>> says </dia:diagram> inclusive as a file with a .dia suffix and that's it.
>
> I know that, but an attachment is sent as text too, so there really
> isn't much of a difference. News servers may still reject them, because
> they're not plain readable text.
>

A mail client can be set to *display* attachments inline when it
receives them. The way that the client recognises attachments is that
the headers have their Content-Type header set to multipart and
declaring a string to differentiate boundaries. The boundary marker is
then used to differentiate body from attachment (and, indeed, plain text
body from HTML body) and handle them accordingly.

Even a plain text attachment is send with the Content-type as multipart.
This really is a significant different between such an attachment and
the inline text. You can check this for yourself by creating a plain
text file, emailing it to yourself and comparing the headers with those
of a plain text email with nothing embedded.

I haven't found any RFCs dealing specifically with Usenet attachments
not have I any examples to check so I would expect *sending* them to
follow the same pattern as emails. Do you have any references defining
something different?

The example I sent has the XML inlines. As I would expect, my client
set the Content-Type set to text/plain with no boundary string set or
used. You can check that for yourself by looking at the message source
and finding the Content-type line.

There are the two short lines of equals signs which I defined in the
body, not the header, and inserted as a guide to manual cutting and
pasting. I fail to see, therefore, how any server would differentiate
text within a plain-text message body and treat it as an attachment
although it might block a message on the basis of length. .

As to readability, XML is, by design, *readable* UTF8 encoded text. It
may not be easy to *interpret* by eye if it is being used to transmit
data encoded as numbers, but the numbers themselves are just expressed
as either short integers or decimal numbers using ordinary ASCII
encoding of numerals. That, however, is a matter of the data being
primarily intended to be processed by an application.

Ian