No proper right alignment possible in pdf

That’s not how PDF is designed to work.

PDF is not just a way to distribute manuals, invoices, etc. It is a general purpose system for transmitting page-based content in a way that is flexible, durable, and system-agnostic. Many PDFs that are generated are never viewed by human beings; they are produced and consumed solely by computer systems.

Because of this design, PDFs can be created to various levels of portability; many such standards have been defined by the industries that use PDF, such as the print industry. For example, a print industry standard might prohibit RGB images, or require that any line in the document be at least .5 pt in width. However, these requirements are specific to the standard involved and are not part of the PDF definition itself.

This flexibility applies to fonts as well. PDF places few restrictions on fonts. A PDF file can have all of its fonts embedded, in which case it will be accurately viewable on any reader; it may have all fonts except the PDF Base Fonts embedded, in which case it should still be accurately viewable on any reader with certain obscure caveats; or may have none of its fonts embedded, in which case it will only be accurately viewable on readers that have access to all the fonts referenced in the document.

All of these scenarios represent 100% valid PDF files, because one of the fundamental principles of PDF is that the reader is responsible for properly dealing with PDFs that reference fonts that aren’t embedded in the document. Adobe’s Acrobat Reader has a sophisticated system that tries to synthesize a font that at least matches the metrics of the missing font; other readers have different algorithms. However, in all cases, it is a required function that the reader deal with unembedded fonts because that is a key feature of the PDF specification.

Why would anyone create a PDF using a font that is not embedded? Because in some situations you can save considerable time and storage space by omitting them with the knowledge that the reader involved already has those fonts available on its system. Recall that PDF harkens from the early 1990s when storage space and network bandwidth were still at a premium and economizing them was a real consideration.

So: the notion that the Xojo framework should take any particular action when code calls for a non-existent font is not a question that relates to the PDF specification. It is perfectly valid for Xojo’s PDF library to create a file that references a font not installed on the current system. The developer or user may want different behavior, and can figure that out on their own or by working with Xojo.

On macOS/iOS, a Graphics context is mapped to a Core Graphics context which uses all the same commands to render both pixel-based graphics and vector-based graphics, using the PDF imaging model. If you are dealing with Core Graphics itself, you can literally redirect your pixel-based imaging efforts into a PDF file with zero loss of fidelity. It’s a fantastically flexible system.

Not sure if this is true of Windows or Linux.

Standard PDF Base 14 Fonts

  • PDF viewers always support these standard fonts:
    • Serif: Times, Times-Bold, Times-Italic, Times-BoldItalic
    • Sans-serif: Helvetica, Helvetica-Bold, Helvetica-Oblique, Helvetica-BoldOblique
    • Monospace: Courier, Courier-Bold, Courier-Oblique, Courier-BoldOblique
    • Symbolic: Symbol, ZapfDingbats

Helvetica is a font of choice of the 14 Base for a simple writer engine to substitute an unknown font due to:

Being modern and proportional, that means Sans-serif and not monospaced (that excludes Times or Courier), and the Symbolic one is not an obvious choice.

That said. The other way could be Xojo embedding some kind of fallback font to be used in case of an unknown font, such font should be readable as Helvetica or Arial or Liberation, but the downside is that it would add size to the PDF.

So I stick with the Helvetica choice.

But why then do the results differ between drawing to a Canvas.Graphics and drawing to a PDFGraphics (under macOS)?

Xojo should know and work on a fix? Right now I only think that some internal math and/or metrics seems not ok leading to that.

Good question. Perhaps they’re not making use of Core Graphics for their PDF generation.

Or they have some common coordinate system layer (math, that 72pixels per inch thing, scaling etc) on top of that, needing adjusts per platform. And some bug/bugs.

What’s important is: the bug was reported. The metrics and spatial coordinates seems off under certain cisrcustances. We have no idea of what happens behind the scenes. Let’s wait Xojo to find a fix.