Re: Doc: typo in config.sgml

On Mon, Nov 11, 2024 at 10:02:15PM +0900, Yugo Nagata wrote:
> On Tue, 5 Nov 2024 10:08:17 +0100
> Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
>
> > >> 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 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.
>
> I found a description in FAQ on Apache FOP [1] that explains some glyphs for
> Latin1 character set are not contained in the standard text fonts.
>
> The standard text fonts supplied with Acrobat Reader have mostly glyphs for
> characters from the ISO Latin 1 character set. For a variety of reasons, even
> those are not completely guaranteed to work, for example you can't use the fi
> ligature from the standard serif font.

So, the failure of ligatures is caused usually by not using the right
Adobe Font Metric (AFM) file, I think. I have seen faulty ligature
rendering in PDFs but was alway able to fix it by using the right AFM
file. Odds are, failure is caused by using a standard Latin1 AFM file
and not the AFM file that matches the font being used.

> [1] https://xmlgraphics.apache.org/fop/faq.html#pdf-characters
>
> However, it seems that using iconv to detect non-Latin1 characters may be still
> useful because these are likely not displayed in PDF. For example, we can do this
> in make check as the attached patch 0002. It cannot show the filname where one
> is found, though.

I was thinking something like:

grep -l --recursive -P '[\x80-\xFF]' . |
while read FILE
do iconv -f UTF-8 -t ISO-8859-1 "$FILE" || exit 1
done

This only checks files with non-ASCII characters.

> > 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.
>
> When a character that cannot be displayed in PDF is found, a warning
> "Glyph ... not available in font ...." is output in fop's log. We can
> prevent such characters from being contained in PDF by checking
> the message as the attached patch 0001. However, this is checked after
> the pdf is generated since I could not have an idea how to terminate the
> generation immediately when such character is detected.

So, are we sure this will be the message even for non-English users? I
thought checking for warning message text was too fragile.

--
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?"