On 02.11.24 14:18, Bruce Momjian wrote:
On Sat, Nov 2, 2024 at 12:02:12PM +0900, Tatsuo Ishii wrote:
Yes, we _allow_ LATIN1 characters in the SGML docs, but I replaced the
LATIN1 characters we had with HTML entities, so there are none
currently.
I think it is too easy for non-Latin1 UTF8 to creep into our SGML docs
so I added a cron job on my server to alert me when non-ASCII characters
appear.
So you convert LATIN1 characters to HTML entities so that it's easier
to detect non-LATIN1 characters is in the SGML docs? If my
understanding is correct, it can be also achieved by using some tools
like:
iconv -t ISO-8859-1 -f UTF-8 release-17.sgml
If there are some non-LATIN1 characters in release-17.sgml,
it will complain like:
iconv: illegal input sequence at position 175
An advantage of this is, we don't need to covert each LATIN1
characters to HTML entities and make the sgml file authors life a
little bit easier.
I might have misread the feedback. I know people didn't want a Makfile
rule to prevent it, but I though converting few UTF8's we had was
acceptable. Let me think some more and come up with a patch.
The question of encoding characters as entities is orthogonal to the
issue of only allowing Unicode characters that have a mapping to Latin
1. This patch seems to confuse these two issues, and I don't think it
actually fixed the second one, which is the one that was complained
about. I don't think anyone actually complained about the first one,
which is the one that was actually patched.
I think the iconv approach is an idea worth checking out.
It's also not necessarily true that the set of characters provided by
the built-in PDF fonts is exactly the set of characters in Latin 1. It
appears to be close enough, but I'm not sure, and I haven't found any
authoritative information on that. Another approach for a fix would be
to get FOP produce the required warnings or errors more reliably. I
know it has a bunch of logging settings (ultimately via log4j), so there
might be some possibilities.
