Release Notes - Version 1.0.0-20261020

A release after 20261019.1: a font is a handle the manifest binds, everywhere. A theme manifest that binds FONT_1 to its own family changes the text set in FONT_1, and a document no longer has to be opened and saved with a theme before it can be printed with it.

Changed in this release

• Choosing a font stores its handle, not its name (TYP-941). The font menu still lists families. A run set in a font now carries only that font's handle (FONT_2, or family:<name> for an uploaded or Google font), and the manifest says which family that handle is. A theme that binds the handle to another family therefore changes this text too, as it already did for converted text.
• Applying a theme rewrites nothing in the document. It binds the handles, and the text follows. Before, applying a manifest wrote the bound family into every run and style, and dropped any handle the manifest did not know.
• A family missing from a converted package has a handle too. It is a manifest entry without a font file. A theme that binds the same handle supplies the file. Until then the family is reported missing and drawn in a substitute face.
• Printing with a theme: no open-and-save first. A saved layout records which family each handle was laid out in. When a print job's manifest binds a handle to another family, the document is laid out again in the theme's fonts before it is printed. If those fonts cannot be loaded, the job fails and names them, rather than printing without that text.
• Older documents are converted when they are opened. A reference that named a family gets that family's handle; a family no font file supplies gets a manifest entry without a file.

Fixed in this release

• File ▸ POD settings ▸ Replace fonts no longer shows a colour square in its "replace with…" buttons. The square belongs to the Document colours column, where the choices are colours.

Typograph developers notes

• editor-ui textcommands.ts applyToSelection(): a font_family from the font menu is turned into font_uuid through canvas's FontManager.reference_uuid(null, family), and the family is not written into the run.
• docs/Embedding.md "Theme fonts": every family gets a handle, a missing one is a manifest entry without a url, and step 4 (print with a theme) no longer asks to open and save with the theme.
• editor-ui podsettingsdialog.ts swatch_chooser(): the button carries a colour chip only when its options are swatches (cherry-picked from fix/pod-font-chooser-no-chip).
• Canvas pin debe5ff (from 7eb6795): canvas #195 (TYP-940), #196 and #194 (CI only). #196 is a fix to #195 found in end-to-end testing: 9834772 wrote uuid into every rich frame's default_font, which document-schema's RichText\Font does not model, so the publisher refused every document saved with it and nothing printed. Public surface for hosts:
  • A saved document changes shape. References carry font_uuid and no font_family, laid-out words carry font_uuid, the template carries layout_fonts ([{uuid, font_family, font_styles}]), and the manifest may hold fonts with url: null. All of it is in document-schema since TYP-939, which every service carries.
  • ⚠️ validate() no longer reports font_not_printed. The state it reported, a stored layout naming a family the print cannot find, is removed by the relayout at print time. A host that blocked orders on it gets nothing to block on.
  • substitute_font() is uuid-only. font_handles() reports the uuid each reference speaks with.
  • A manifest font without a url is a binding: it is no longer loaded from '', which recorded a load error. A family a theme has since loaded is no longer reported as a font issue.
• Before this deploys, print must be ready for these documents:
  • publisher-service with the document-generator bump (TYP-943) live: today's live generator rejects a manifest font without a url ("Font URL is required.");
  • publisher-service TYP-945 live, with CANVAS_SERVICE_URL set on x1;
  • canvas-service on x1 at master with canvas debe5ff (TYP-944 and its pin bump): the relayout calls its /layout. ⚠️ Never with canvas 9834772: its layouts do not validate.
• The epic is TYP-938: schema TYP-939, canvas TYP-940, converter TYP-942 (with the converter-service bump), document-generator TYP-943, canvas-service TYP-944, publisher-service TYP-945. Known gap: TYP-947, a print job's URL header rules do not reach canvas-service yet.