[lucida] PDF font embedding for PDF/A, problem using Type 1 with accented characters

[John H Lienhard]

Thank you for this detailed analysis, Bruno.

Following on your suggestion that pdfmanagement-testphase might be involved, I have corresponded with Ulrike Fischer.  While the cause of this issue remains unclear, Ulrike offered the following suggestion which has resolved the issue I was seeing:

try with

\pdfomitcharset = 1

or with lualatex with

\pdfvariable omitcharset = 1

By adding the first line to my preamble (under pdflatex), the test file I sent now creates valid PDF/A output with the accented characters.

As a side note, I have now seen a similar problem with accented characters in the dejavu serif font when fontenc is loaded first, but for that font the issue disappears when fontenc is NOT loaded.  I do not see the issue with LMR and some packages that load fontenc internally – erewhon, crimson, XCharter.  So the problem is sensitive to the font choice, and is not entirely unique to Lucida.

            Cheers,
            John


From: Bruno Voisin <bvoisin at icloud.com>
Date: Thursday, February 16, 2023 at 1:56 AM
To: John H Lienhard <lienhard at mit.edu>
Cc: lucida at tug.org <lucida at tug.org>
Subject: Re: [lucida] PDF font embedding for PDF/A, problem using Type 1 with accented characters
> On 15 Feb 2023, at 21:42, John H Lienhard <lienhard at mit.edu> wrote:
>
> Accented characters (say, \’{e} or é) appear to break pdf/a compliance with Lucida type 1 fonts.  Running the test file below, and then checking with Acrobat preflight shows that pdf/a compliance is lost if I uncomment either line with accents. Preflight states:
>
>  “CharSet in subset font is incomplete (contains glyphs that are not listed)”

Beware: I'm no expert at all with Acrobat. It took me several minutes to find where preflight lives in the UI of the latest Acrobat Pro, then several attempts to figure out how to run that preflight thing to check for PDF/A-3u compliance.

It seems:

- With the Type 1 fonts, the problem arises with pdfTeX and LuaTeX, but everything's OK with XeTeX.

- With the OpenType fonts, no problem with either LuaTeX or XeTeX.

Generally (hoping Karl Berry corrects me if I'm wrong), I think the Type 1 fonts are provided essentially "as is", they won't be updated. The way forward is the OpenType version (provided you're at ease with fontspec and unicode-math).

Another solution is the pdfx package. Namely, replacing your example with

\documentclass[letterpaper]{book}
\usepackage{lipsum}
\usepackage[a-3u]{pdfx}
\usepackage[LY1]{fontenc}
\usepackage[expert,vargreek,altbullet,seriftt,LY1]{lucidabr}

\begin{document}
\lipsum[1]

\'{e} \`{e}

è é

\end{document}

This seems to work with pdfLaTeX, preflight reports everything's fine. I tested very quickly. To be double-checked.

There are several StackExchange pages on how to produce PDF/A files with LaTeX, but they're not necessarily current. I found the tip about the pdfx package through a Google link to an Overleaf template

https://www.overleaf.com/latex/templates/creating-pdf-slash-a-and-pdf-slash-x-files-with-the-pdfx-package/bbbycnbyqhnm

Overleaf's help otherwise has a very complete article on producing tagged and standard-compliant PDF output with LaTeX

https://www.overleaf.com/learn/latex/An_introduction_to_tagged_PDF_files%3A_internals_and_the_challenges_of_accessibility

The pdfmanagement-testphase package you're using (given your \DocumentMetadata) seems to say in its doc that pdfx will be replaced by native LaTeX support for PDF standards. Looking at the doc for the l3pdfmeta module, it's unclear what the user interface is for this functionality. Maybe this is precisely the "pdfstandard = A-3u" you're using.

Bruno Voisin

PS Recently, looking at the LaTeX 3 codebase, I realized LaTeX 3 deviates from the original model of defining engine-specific commands in separate driver files. Instead, the LaTeX 3 core files include engine-specific definition of some commands. I regard this as a very unfortunate choice, making it difficult nay impossible to get LaTeX 3 to work with additional engines (I realized the above while attempting to run pdfmanagement-testphase with the built-in TexpadTeX engine of Texifier). All this to say: maybe the above is a LaTeX 3 bug, to be reported to the LaTeX 3 team so they correct their pdfTeX- and LuaTeX-specific definitions of some commands used by pdfmanagement-testphase.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/lucida/attachments/20230216/07f2f681/attachment.html>