PdfSharpCore font size units is not making sense and doesn't seem right

Question

I'm confused by the font sizes in PdfSharpCore. The documentation for XFont says that the font size is specified as "emSize".

According to w3.org, em size represents the font size. According to W3 Schools, The size of an EM or percent depends on its parent. And according to Wikipedia, it originally meant the width of the letter 'M'.

How is it possible to specify the font size using the size of a font, a value that depends on its "parent" or based on any other attribute of an existing font when there is no existing font?

In practice, the value I specify appears to be interpreted as very close to points. But if it is really specifying points, why would it be documented as "emSize?"

Can anyone clarify how I can use an em size to set the font size? What em size would I use to specify 14 point?

Answer 1

The XFont class has an emSize parameter because it mimics the Font class of GDI+ which already has an emSize parameter. That is the simple explanation why the developer of PDFsharp chose that name (I asked him). I did not yet find further information why Microsoft chose that name.

emSize is the name of the parameter, but the unit is not em. The default unit is Point, but other units can be set. The emSize parameter defines the em of the font to be used.

Forget the W3C documentation in this case: This is not CSS, there is no "parent" and no option to use relative sizes (percent values).

To get a font of size 14 points, just specify 14. The emSize parameter specifies the height of the font.

The answer by K J might explain how Microsoft came to the name emSize.

From Wikipedia: "An em (from English em quadrat) is a unit in the field of typography, equal to the currently specified point size. For example, one em in a 16-point typeface is 16 points. Therefore, this unit is the same for all typefaces at a given point size."
https://en.wikipedia.org/wiki/Em_(typography)

From the Font documentation linked below: "The em-size, in points, of the new font."
From the PDFsharp XML documentation: "Gets the em-size of this font measured in the unit of this font object." The default unit is points. So with PDFsharp the value "14" gives a font height of 14 points.

See also:
https://learn.microsoft.com/en-us/dotnet/api/system.drawing.font.-ctor?view=windowsdesktop-8.0#system-drawing-font-ctor(system-string-system-single)

Answer 2

Technically, per PDF specification, the font size in 'Tf' operator is just a scale factor.
The final font size is given by this formula:

|Tfs×Th   0    0|
|  0    Tfs    0| × Tm × CTM
|  0    Trise  1|

Tfs   - text font size for Tf operator (usually the font size in the API)
Th    - text horizontal scaling
Trise - text rise
Tm    - text matrix
CTM   - current transformation matrix

Assuming the default user unit is the PDF point, the Tm and CTM are identity matrices (no scaling), Trise=0, Th=100 (no scaling), then the final font size is Tfs in PDF points.

Answer 3

To see where emSize originates we need to go back in time to the Printers Manuals when Modern MECHANICK printing started and the best source is the PDF from 1683 where all letters were described as based on 42 units x 42 units as described on page 98-99 starting with

..the divided Line on the
Left Hand of A is divided into forty and two equal
Parts ; and that Length is the Body, thus : J being
an Aʃcending and Deʃcending Letter, viz. a long
Letter, ʃtands upon forty two Parts, and therefore
fills the whole Body.
....
And as there is three Heighths or Sizes to be con-
ʃidered in Letters Cut to the ʃame Body, ʃo is there
three Sizes to be conʃidered, with reʃpect to the
Thickneʃʃes of all theʃe Letters, when the Punches
are to be Forged : For ʃome are m thick ; by m
thick is meant m Quadrat thick, which is juʃt ʃo thick
as the Body is high : Some are n thick ; that is to
say, n Quadrat thick, viz. half ʃo thick as the Body
is high : And ʃome are Space thick ; that is, one
quarter ʃo thick as the Body is high ; though Spaces
are ʃeldom Caʃt ʃo thick, as ʃhall be shewed when
we come to Caʃting : and therefore, for diʃtinction
ʃake, we ʃhall call theʃe Spaces, Thick Spaces.

There were exceptions then too

... moʃt of the
Swaʃh Letters ; which being too thick to ʃtand on
an m, muʃt be Forged thicker, according to the
Work-man’s Reaʃon.

We would call that in modern terms the "Draughtsman's License"

Note they could have called it 1 bodySize or jaySize but it was easier to describe the variable of widths by the most quadratile of all the ascendant letters. the finished size of any fount was based on a stock width of the M. Thus the overall "Fount Body" size was considered its "m Size", an abstract value based on square width = height.

Then as now the programming consideration was the precise width of a line of text (using variable height letters) so the page Rule Length/Width would be based on a total number of m's. Today we would use for matrix line printers such as POS roll printing 10cpi or 12cpi.

Thus for a font of approximately 14 points high the exact emSize will be 14 points.

In programming we describe a font just as then

family, emSize, style

Roman, 14, italic

Where the emSize is 14 units (traditionally was pica's wide, but in PDF=points not CPI nor mm nor other CGI pixel unit length)

In Engineering we may say let emSize = 2 mm high to get precision of exactly 2 mm high letters

In Wooden Press we may say let emSize= 2" wide for block printing

In PDF term we say let emSize - ## points for a highly variable range of fonts where none actually use a fixed height or width but are based on the abstract square unit of ##x1/72"