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

[Bruno Voisin]

> 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 --------------
A non-text attachment was scrubbed...
Name: lienhard_otf.tex
Type: application/octet-stream
Size: 227 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20230216/4ef358e7/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lienhard_type1_pdfx.tex
Type: application/octet-stream
Size: 234 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20230216/4ef358e7/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lienhard_type1.tex
Type: application/octet-stream
Size: 264 bytes
Desc: not available
URL: <https://tug.org/pipermail/lucida/attachments/20230216/4ef358e7/attachment-0002.obj>
-------------- next part --------------