<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Mangal;
panose-1:2 4 5 3 5 2 3 3 2 2;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1548955662;
mso-list-type:hybrid;
mso-list-template-ids:770758524 1347304868 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F06E ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:Mangal;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7 ;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">Ulrike has found the root cause of this issue, in the afm file. Here is her analysis:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:#1D1D1D;background:white">The lucida afm shows that the accented chars in this font are</span><span style="color:#1D1D1D"><br>
<span style="background:white">composites: the egrave is actually e + grave:</span><br>
<br>
<span style="background:white">CC egrave 2 ; PCC e 0 0 ; PCC grave -32 0 ;</span><br>
<br>
<span style="background:white">If you compile a document using only é and è you get a charset</span><br>
<br>
<span style="background:white">/CharSet (/eacute/egrave)</span><br>
<br>
<span style="background:white">and this misses the underlying chars, and so acrobat quite rightly<span class="apple-converted-space"> </span></span><br>
<span style="background:white">complains that the document/font uses chars not declared in the<span class="apple-converted-space"> </span></span><br>
<span style="background:white">/CharSet.</span><br>
<br>
<span style="background:white">If one forces the use of the underlying chars</span><br>
<br>
<span style="background:white">é è e \char19 \char18</span><br>
<br>
<span style="background:white">then the charset contains</span><br>
<br>
<span style="background:white">/CharSet (/acute/e/eacute/egrave/grave)</span><br>
<br>
<span style="background:white">and acrobat is happy again as now all used glyphs are declared.</span><br>
<br>
<span style="background:white">So on the whole I would say this is a bug in the pdftex engine (and<span class="apple-converted-space"> </span></span><br>
<span style="background:white">perhaps also luatex).<span class="apple-converted-space"> </span></span><br>
<br>
<span style="background:white">(But as /CharSet is only mandatory for pdf/A-1 I think it isn't such a<span class="apple-converted-space"> </span></span><br>
<span style="background:white">pressing issue and I will add a switch to suppress the charset)<span class="apple-converted-space"> </span></span></span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">--- John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">lucida <lucida-bounces+lienhard=mit.edu@tug.org> on behalf of John H Lienhard <lienhard@mit.edu><br>
<b>Date: </b>Thursday, February 16, 2023 at 10:40 AM<br>
<b>To: </b>Bruno Voisin <bvoisin@icloud.com><br>
<b>Cc: </b>lucida@tug.org <lucida@tug.org><br>
<b>Subject: </b>Re: [lucida] PDF font embedding for PDF/A, problem using Type 1 with accented characters<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt">Thank you for this detailed analysis, Bruno.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="color:#1D1D1D;background:white">try with<span class="apple-converted-space"> </span></span><span style="color:#1D1D1D"><br>
<br>
<span style="background:white">\pdfomitcharset = 1<span class="apple-converted-space"> </span></span><br>
<br>
<span style="background:white">or with lualatex with</span><br>
<br>
<span style="background:white">\pdfvariable omitcharset = 1</span></span><o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">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.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> Cheers,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> John</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Bruno Voisin <bvoisin@icloud.com><br>
<b>Date: </b>Thursday, February 16, 2023 at 1:56 AM<br>
<b>To: </b>John H Lienhard <lienhard@mit.edu><br>
<b>Cc: </b>lucida@tug.org <lucida@tug.org><br>
<b>Subject: </b>Re: [lucida] PDF font embedding for PDF/A, problem using Type 1 with accented characters</span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">> On 15 Feb 2023, at 21:42, John H Lienhard <lienhard@mit.edu> wrote:<br>
> <br>
> 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:<br>
> <br>
> “CharSet in subset font is incomplete (contains glyphs that are not listed)”<br>
<br>
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.<br>
<br>
It seems:<br>
<br>
- With the Type 1 fonts, the problem arises with pdfTeX and LuaTeX, but everything's OK with XeTeX.<br>
<br>
- With the OpenType fonts, no problem with either LuaTeX or XeTeX.<br>
<br>
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).<br>
<br>
Another solution is the pdfx package. Namely, replacing your example with<br>
<br>
\documentclass[letterpaper]{book}<br>
\usepackage{lipsum}<br>
\usepackage[a-3u]{pdfx}<br>
\usepackage[LY1]{fontenc}<br>
\usepackage[expert,vargreek,altbullet,seriftt,LY1]{lucidabr} <br>
<br>
\begin{document}<br>
\lipsum[1]<br>
<br>
\'{e} \`{e}<br>
<br>
è é<br>
<br>
\end{document}<br>
<br>
This seems to work with pdfLaTeX, preflight reports everything's fine. I tested very quickly. To be double-checked.<br>
<br>
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<br>
<br>
<a href="https://www.overleaf.com/latex/templates/creating-pdf-slash-a-and-pdf-slash-x-files-with-the-pdfx-package/bbbycnbyqhnm">https://www.overleaf.com/latex/templates/creating-pdf-slash-a-and-pdf-slash-x-files-with-the-pdfx-package/bbbycnbyqhnm</a><br>
<br>
Overleaf's help otherwise has a very complete article on producing tagged and standard-compliant PDF output with LaTeX<br>
<br>
<a href="https://www.overleaf.com/learn/latex/An_introduction_to_tagged_PDF_files%3A_internals_and_the_challenges_of_accessibility">https://www.overleaf.com/learn/latex/An_introduction_to_tagged_PDF_files%3A_internals_and_the_challenges_of_accessibility</a><br>
<br>
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.<br>
<br>
Bruno Voisin<br>
<br>
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.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"> <o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>