Re: Doc: typo in config.sgml

On Tue, Oct 15, 2024 at 10:10:36AM +0900, Yugo NAGATA wrote:
> Hi Bruce,
>
> On Mon, 14 Oct 2024 16:31:11 -0400
> Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> > On Mon, Oct 14, 2024 at 03:05:35PM -0400, Bruce Momjian wrote:
> > > I did some more research and we able to clarify our behavior in
> > > release.sgml:
> >
> > I have specified some more details in my patched version:
> >
> > We can only use Latin1 characters, not all UTF8 characters,
> > because some rendering engines do not support non-Latin1 UTF8
> > characters. Specifically, the HTML rendering engine can display
> > all UTF8 characters, but the PDF rendering engine can only display
> > Latin1 characters. In PDF files, non-Latin1 UTF8 characters are
> > displayed as "###".
> >
> > In the SGML files we encode non-ASCII Latin1 characters as HTML
> > entities, e.g., &Aacute;lvaro. Oddly, it is possible to safely
> > represent Latin1 characters in SGML files as UTF8 for HTML and
> > PDF output, but we we currently disallow this via the Makefile
> > "check-non-ascii" rule.
> >
>
> I agree with encoding non-Latin1 characters and disallowing non-ASCII
> characters totally.
>
> I found your patch includes fixes in *.svg files, so how about checking
> also them by check-non-ascii? Also, I think it is better to use perl instead
> of grep because non-GNU grep doesn't support hex escape sequences. I've attached
> a updated patch for Makefile. The changes in release.sgml above is not applied
> yet, though.

Yes, good idea on using Perl and checking svg files --- I have used your
Makefile rule.

Attached is an updated patch. I realized that the new rules apply to
all SGML files, not just the release notes, so I have created
README.non-ASCII and moved the description there.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

When a patient asks the doctor, "Am I going to die?", he means
"Am I going to die soon?"