Not off-topic: Wrong couple divorced after computer error by law firm Vardag's

Fri Apr 26 15:13:12 CEST 2024

On Fri, 26 Apr 2024 at 07:35, Paulo Ney de Souza <pauloney at gmail.com> wrote:

> Kaveh,
>
> Since you asked, I'd be happy to! I am going to concentrate my critique on
> faults that are likely due to the TeX coming directly from XML and the
> operator not wanting to spend the time to go back and insert the directives
> in the XML file.
>
> Letś start with the article:
>
> Non-local distance functions and geometric regularity
> Max Engelstein, Cole Jeznach, Svitlana Mayboroda
> URL: https://www.sciencedirect.com/science/article/pii/S0001870824001646
>
> Letś start by looking at the inter-word spacing in the Abstract:
>
> [image: Screenshot from 2024-04-25 22-00-03.png]
>
> It hurts the eye, just look as it goes increasing from line one to the
> next and the next all the way to the letter "a" by itself on line 4.
>
> This thing is so awful that amazingly, the typography arranged by Blink on
> HTML on  Chrome is much, much better.
>
> [image: Screenshot from 2024-04-25 22-09-21.png]
>
>
They do not have right-justification, but could and still would look better.
>

The above article is not Open Access, so I can only comment on what I see
here...

The PDF line width is narrower and as you say it is justified, so harder to
get good looking lines. I think justification is over-used.

So most of the issues above are TeX style issues. It would even be possible
to have a filter that would automatically tie "A" to the next word at the
beginning of a sentence if that is what is required.

>
> Look at the size of this accent on the letter K, starting around page 10
> of the paper:
>
> [image: Screenshot from 2024-04-25 22-17-14.png]
>
> It is so small that it is appropriate only for the letters A and I --
> ONLY!  Here, most likely, the size variations were not defined in the XML
> and the operator was too lazy to go back and insert the directives that
> could be used into TeX for the proper typesetting. The size of the accent
> is totally inappropriate.
>
> Here are a couple of examples where the operator probably did go back to
> insert directives for a larger parens around the radical sign:
> [image: Screenshot from 2024-04-25 22-33-17.png]
>
> but ignore it on the second occurrence of the same thing:
>
>
> [image: Screenshot from 2024-04-25 22-29-35.png]
>
>
>
The points you make regarding the above I feel are not major, compared to
many other problems that published articles have. I think that if
the MathML is correctly structured it is possible to use "left" and "right"
for brackets automatically. And the tilde, perhaps an automated filter too.
But to my eye the tilde is not a major problem. Your standards are probably
higher than most!

> Here is an article:
>
> Classification générique de synthèses temps minimales avec cible de
> codimension un et applications
> B. Bonnard, G. Launay, M. Pelletier
> https://doi.org/10.1016/S0294-1449(97)80149-7
>
> that runs 48 pages without a SINGLE hyphenation for line break. I have
> never seen anything like that.
>

Quite common and again simple style file problem I would say.

>
> It does look like someone typeset the article in English, saw the many
> erroneous line-breaks and instead of going back and changing the language,
> they went back and inserted \sloppy at the top of the file. We are only
> humans, and when one has a hammer everything in the world looks like a nail.
>
> Inserting directives for kerning, tracking, etc ... in XML to be used by
> TeX rendering is a shitty job and most people are willing to ditch it.
>

In my opinion, the content should be structured correctly in the XML and we
so what we can to automate kerning etc in the rendering stage.

>
> I am finishing a Math Problem Book with one of the Big-Two. The book that
> was initially written in a MySQL database of problems and solutions has
> been converted to XML. Every time I have a small finx on the kerning of an
> element of a matrix, I have to send the request for the fix, hoping they
> will understand it and fix it. The turn around is a week, in which case, if
> correct, - we just move down to the next line of the matrix and do it
> again. A process that is guaranteed NOT to converge.
>
> Of course a lot of what is good and bad in typography is a matter of taste
> and discussion. But no matter what measure you come up with -- be it the
> badness index of Knuth--Plass or a wider distribution of inter-word spacing
> .. or any other one, we could probably use it to show that XML is the
> source of large amounts of bad typography in the world right now.
>

But what is the solution? We cannot have TeX files as the source,
because TeX is not structured. It is for typesetting. So we need simple
tagging for content and the best possible rendering with minimal manual
work. I have learned to live with slightly bigger or smaller brackets, but
ensuring truly futureproof content.

>
> Hope you are looking more convinced now. Best,
>
> Paulo Ney
>
>
>
>
>
>
>
> On Tue, Apr 23, 2024 at 12:15 AM Kaveh Bazargan <kaveh at rivervalley.io>
> wrote:
>
>> Hello Paulo
>>
>> Could you possibly point to an example, e.g. an Open Access Elsevier
>> paper and where you see the bad typography? In general, the settings for
>> the class and style files should ensure that only rarely TeX-specific
>> commands need to be used.
>>
>> On Mon, 22 Apr 2024 at 23:02, Paulo Ney de Souza <pauloney at gmail.com>
>> wrote:
>>
>>> We do that ALL the time, not on lines on a poster, but with lines on
>>> Bibliographies.
>>>
>>> It used to be an extremely cumbersome and expensive procedure
>>> during BibTeX times, when TeX did not know the language it was
>>> typesetting a bibliography entry. It got infinitely better with BibLaTeX.
>>>
>>> Of course, it is possible to annotate the XML with inter-word and inter-
>>> character spacing information, but it is plain NOT done, most likely
>>> because of the costs involved.
>>>
>>> Just open the Bibliography of an Elsevier published article processed
>>> with TeX, especially the ones with two columns, it is absolutely awful,
>>> with absurd spacing in the wrong places and incorrect hyphenation
>>> of words. It does look like they have the command \sloppy at the start
>>> of every Biblio and hyphenate everything in English no matter what
>>> is written in the text.
>>>
>>> I am publishing a book with one of the big publishers and it has been
>>> converted to XML. At every complaint of a bad line break or wrong
>>> hyphenation they take a week to respond and, in general, with another
>>> bad line-break or hyphenation caused by the previous fix.
>>>
>>> Kaveh, if you know an efficient and inexpensive way to do this, you
>>> could probably teach us because this is probably holding up the adoption
>>> of XML as a source, by authors. What about a talk at TUG'24?
>>>
>>> Paulo Ney
>>>
>>>
>>> On Mon, Apr 22, 2024 at 12:23 PM William F Hammond <hmwlfsr at yahoo.com>
>>> wrote:
>>>
>>>> I ended my last message with this:
>>>>
>>>>     But if I want to be fussy about typesetting I will use
>>>>     regular LaTeX.
>>>>
>>>> Speaking about fussy typesetting, one case is that of a long
>>>> paragraph in a public poster on a wall (with suitably large
>>>> fonts).  I think it desirable to have both left and right
>>>> flush margins and no line-ending hyphens.  Usually, though
>>>> not always, I can tease that out of LaTeX with micro
>>>> adjustments to line width.  Failing that, I may need to make
>>>> manual adjustments to the inter-word spaces in a few lines.
>>>> But is there a package that attempts to do this?
>>>>
>>>>           -- Bill
>>>>
>>>>
>>>>
>>>> https://www.facebook.com/william.f.hammond
>>>> http://www.albany.edu/~hammond/
>>>>
>>>> 𝑻𝒉𝒆 𝒕𝒊𝒎𝒆 𝒕𝒐 𝒔𝒂𝒗𝒆 𝒂 𝒅𝒆𝒎𝒐𝒄𝒓𝒂𝒄𝒚 𝒊𝒔 𝒃𝒆𝒇𝒐𝒓𝒆
>>>> 𝒊𝒕 𝒊𝒔 𝒍𝒐𝒔𝒕.
>>>>    -- 𝐊𝐞𝐧 𝐁𝐮𝐫𝐧𝐬
>>>>
>>>>
>>>>
>>
>> --
>> Kaveh Bazargan PhD
>> Director
>> River Valley Technologies <http://rivervalley.io> ● Twitter
>> <https://twitter.com/rivervalley1000> ● LinkedIn
>> <https://www.linkedin.com/in/bazargankaveh/> ● ORCID
>> <https://orcid.org/0000-0002-1414-9098> ● @kaveh1000 at mastodon.social
>> <https://mastodon.social/@kaveh1000>
>> *Accelerating the Communication of Research*
>>
>> *
>> <https://www.linkedin.com/posts/bazargankaveh_ismte-innovation-award-recipient-kaveh-bazargan-activity-7039348552526921728-XAEB/?utm_source=share&utm_medium=member_desktop>  [image:
>> https://rivervalley.io/gigabyte-wins-the-alpsp-scholarly-publishing-innovation-award-using-river-valleys-publishing-technology/]
>> <https://rivervalley.io/gigabyte-wins-the-alpsp-scholarly-publishing-innovation-award-using-river-valleys-publishing-technology/>*
>>
>

-- 
Kaveh Bazargan PhD
Director
River Valley Technologies <http://rivervalley.io> ● Twitter
<https://twitter.com/rivervalley1000> ● LinkedIn
<https://www.linkedin.com/in/bazargankaveh/> ● ORCID
<https://orcid.org/0000-0002-1414-9098> ● @kaveh1000 at mastodon.social
<https://mastodon.social/@kaveh1000>
*Accelerating the Communication of Research*

*
<https://www.linkedin.com/posts/bazargankaveh_ismte-innovation-award-recipient-kaveh-bazargan-activity-7039348552526921728-XAEB/?utm_source=share&utm_medium=member_desktop>
 [image:
https://rivervalley.io/gigabyte-wins-the-alpsp-scholarly-publishing-innovation-award-using-river-valleys-publishing-technology/]
<https://rivervalley.io/gigabyte-wins-the-alpsp-scholarly-publishing-innovation-award-using-river-valleys-publishing-technology/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20240426/ec9197e7/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2024-04-25 22-00-03.png
Type: image/png
Size: 92649 bytes
Desc: not available
URL: <https://tug.org/pipermail/texhax/attachments/20240426/ec9197e7/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2024-04-25 22-09-21.png
Type: image/png
Size: 61238 bytes
Desc: not available
URL: <https://tug.org/pipermail/texhax/attachments/20240426/ec9197e7/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2024-04-25 22-17-14.png
Type: image/png
Size: 6716 bytes
Desc: not available
URL: <https://tug.org/pipermail/texhax/attachments/20240426/ec9197e7/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2024-04-25 22-29-35.png
Type: image/png
Size: 9335 bytes
Desc: not available
URL: <https://tug.org/pipermail/texhax/attachments/20240426/ec9197e7/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2024-04-25 22-33-17.png
Type: image/png
Size: 10356 bytes
Desc: not available
URL: <https://tug.org/pipermail/texhax/attachments/20240426/ec9197e7/attachment-0009.png>