I���ve traced this to the /CharSet for the subsetted  DavidCLM-Medium  font, which is as follows:

For the (fully-validating) PDF created using LaTeX+dvips+GS, the CharSet lists two extra glyphs:

That last line has also:  /quotesingle  and  /space  listed as glyphs in the subsetted font.

My understanding of this is that the /CharSet (if present) should contain the names of all glyphs that are present in the subset font, not just the names of all the characters actually used within the document ��� at least for PDF/A validation.

The latter is OK for a PDF document to work, but is not sufficient for PDF/A.

It is possible for the two lists to be different when the font program for a character calls upon other glyph(s) in building the character shape; e.g. with an accented letter, calling upon separate glyphs for the base and accent. In such a case of an accented letter PDF/A expects *all* of the pieces to be listed in the /CharSet ; e.g, /agrave /a /grave  when �� is present.

I���ve had examples of fonts building some accented letters this way, and have worked around the validation issue by typesetting the bare accents way off the page, to ensure that they are in the subset. But this is a horrible hack that few people will find, nor want to use in a real-world document.

This example with  hebart.pdf  cannot be worked-around, as:

 1.  TeX cannot easily be persuaded to include  /space  within the font subset;

 2.   /quotesingle  is listed in the encoding vector of the font in slot 39, but the quote character is mapped to a Hebrew quote as slot 215 in the font, so the actual glyph cannot be placed into the PDF (so far as I���ve tried).

GS is presumably aware of the problem so builds its CharSets correctly for PDF/A. (Or maybe there is another good reason for doing this.) It���s inclusion of  /space  is interesting; but this is desirable for another request that I���ve made, concerning ���Reflow���-ing a PDF. 

So could developer(s) please have a look at altering how the CharSet is built.