KOMA & mathbbol: wrong font width in PDF

Question

How can I use KOMA-Script along with the package mathbbol?

%\documentclass{article} % works
\documentclass{scrartcl} % fails

\usepackage{mathbbol}
\usepackage{pdfx} % just to calm PDF/A-validators a bit

\begin{document}
\thispagestyle{empty}
$\scriptstyle\mathbb{E}$
\end{document}

pdflatex (TeX Live 2019 on Ubuntu 18.04 LTS) does not report any error or warning. However, both veraPDF and Acrobat's Preflight complain about one and the same font inconsistency. veraPDF states

<validationReport profileName="PDF/A-1B validation profile" statement="PDF file is not compliant with Validation Profile requirements." isCompliant="false">
  <details passedRules="102" failedRules="1" passedChecks="398" failedChecks="1">
    <rule specification="ISO 19005-1:2005" clause="6.3.6" testNumber="1" status="failed" passedChecks="0" failedChecks="1">
      <description>For every font embedded in a conforming file and used for rendering, the glyph width information in the font dictionary and 
                   in the embedded font program shall be consistent.</description>
      <object>Glyph</object>
      <test>renderingMode == 3 || isWidthConsistent == null || isWidthConsistent == true</test>
      <check status="failed">
        <context>root/document[0]/pages[0](5 0 obj PDPage)/contentStream[0](7 0 obj PDContentStream)/operators[11]/usedGlyphs[0](ZCDUID+BBOLD7 69 0  0)</context>
      </check>
    </rule>
  </details>
</validationReport>

and Acrobat's Preflight says

List of glyph width mismatches (PDF data versus embedded font data)
  649.3 versus 676.593 (676.593/1000)

FontForge confirms the width (676 where "Em Size" is 1000) of BBOLD7 in the PDF and RUPS (or $EDITOR) effectively shows

<<  /Type /Font  /FirstChar 69  /LastChar 69  /Widths [649.3]  …  >>

What is the trigger for this inconsistency?

The package pdfx seems to not affect this issue. The issue vanishes if the class article is used, or \scriptstyle or \mathbb is removed, or the package mathbbol is replaced with amssymb.

Answer 1

The fonts bbold7 etc. were originally designed in MetaFont and used MetaFont's facilities to generate lots of optically scaled fonts. Therefore for every fontsize, the font, including the width of the letters, is slightly different. (That's why there are bbold5/bbold7/bbold10.) These MetaFont fonts ended up as Type 3 bitmap fonts in the PDF, so today we prefer vector fonts, in this case in Adobe's Type 1 format. The vector version of bbold only exists in three sizes: 5, 7 and 10, but only providing these three sizes would lead to slight changes to all LaTeX documents using these fonts.

Especially the font metrics (mostly width/depth/height of every character) shouldn't change whether you use the Type 1 or MetaFont version, so LaTeX still loads tfm files (where TeX reads font metrics from) for all sizes which originally had separate fonts, which are 5, 6, 7, 8, 9, 10, 12 and 17.

Every size is mapped to the closed existing Type 1 version. Then this closest version is rescaled to get to the right size. This loses the slight variations that were originally present in all optical sizes, but because TeX still uses the original tfm files TeX still reserves the same amount of space for every character, leading to less overall changes in existing documents. Now because these tfm files actually describe versions of the font for which no vector fonts exists, the metrics, especially the width, does not match the actual width in the font file which leads to these errors.

What can you do about it? If you don't mind changing your font metrics a little bit, you can tell LaTeX to only use metrics for the existing fonts:

% \documentclass[11pt]{article} % works
\documentclass[11pt]{scrartcl} % works

\DeclareFontFamily{U}{bbold}{}
\DeclareFontShape{U}{bbold}{m}{n}
{  <5> <6> bbold5
   <7> <8> bbold7
   <9> <10> <10.95> <12> <14.4> <17.28> <20.74> <24.88> bbold10
}{}
\usepackage{mathbbol}
\usepackage{pdfx} % just to calm PDF/A-validators a bit

\begin{document}
\thispagestyle{empty}
$\scriptstyle\mathbb{E}$
\end{document}

If you prefer the existing solution instead and want to keep the metrics from the original fonts, even if the corresponding fonts no longer exists, you could create virtual fonts bbold6/8/9/12/17 which explicitly load the rescaled glyphs from bbold5/7/10. Using virtual fonts instead of just using wrong font metrics ensures that pdfTeX understands what you are doing and reports this correctly in the PDF file.

But I would recommend trying the above solution first, because creating virtual fonts for this is significantly more complicated.