Dream big: your ideal composition / typesetting software

Joshua Langman · June 8

All right, denizens of TypeDrawers. I've been increasingly frustrated by the slow pace of development on InDesign and the very long list of bugs that have gone unaddressed. In addition to which, the focus of Adobe as a company these days is unrelated to anything for which I use their software. So why not dream big? If you were to create a new piece of typography software from scratch, what would you like to see included?

I'll start the discussion with some features I have long desired, in vain, in ID:

A paradigm of design and composition derived from the way book designers traditionally notate specifications. A platform dedicated to typography, not graphic design. A tool made for serious typographers and compositors who design and typeset books and other printed materials. Perhaps an interface inspired by the design sketches of, say, Richard Eckersley.

Contextual/conditional paragraph styling. E.g., if paragraph A is styled as a subhead, paragraph B will automatically begin full-out. The ability to write sophisticated chains of reasoning for automating par styling.

Some built-in understanding of the parts of a scholarly or literary text: subheads, extracts, notes, dialogue, stage directions, citations … the ability to place a marker in a text saying, e.g., EXTRACT STARTS HERE, and have all subsequent pars style accordingly until an END EXTRACT marker. Nested markers for nested extracts, subheads within extracts, etc.

A sophisticated hyphenation engine. The ability to assign multiple ranked dictionaries: e.g., check for a word in dictionary A; if not found, consult dictionary B, and so on. Controls for limiting the breaking of already hyphenated words, limiting hyphenation / line breaks within the last # chars of a paragraph, or the first/last # of chars within a quotation or parenthetical.

The ability to write cross-font kerning pairs for, e.g., kerning roman delimiters against ital letters.

A choice regarding how letterforms align against margins: (a) align to sidebearings; (b) align to rightmost/leftmost point on letterform glyph; (c) hang punctuation (with options); (d) optical margin.

An option to justify by "counter reshaping": stretch/condense the counterforms of glyphs without changing their stroke weight. Would be used very subtly in conjunction with word spacing and letterspacing.

Dynamic sidenotes.

Some sort of protection of the text itself. Quark now touts new AI tools for rewriting text, demonstrating a complete misunderstanding of their market. Typographers in ordinary circumstances may not alter their copy at all. It would be nice to have software that understands this and at least flags it as a potential issue or asks "Are you sure?". The difference between typesetting software and word processing software.

Color-coded highlighting of paragraph styles, character styles, GREP styles.

An interface for setting tables that mimics that of early dedicated typesetting machines, not spreadsheet logic.

Integrated math typesetting. Integrated charts and graphs. Ideally, integrated music engraving, or at least support for placing music directly from a music engraving program.

Native support for all the many kinds of finessing I routinely do with GREP styles; see other threads.

Native support for ME and CJK scripts. A composition engine designed from the ground up for global text.

A way to define a span of text and do something to it, such as put it in a box, add a diagonal strikethrough, add a horizontal brace over it, add a syllable marking for prosody. A way to say START BRACE HERE and END BRACE HERE.

Letterspacing applied to a range of text, but only within the range, not after the last character.

Baseline grids per page, spread, textblock.

An interface that uses traditional typographic terminology.

Tools for imposition and prepress.

No bloat. No AI. No tools for video or web stuff. MAYBE XML export or some such thing for e-books. But fundamentally a tool for composing printed text.

A program that is not web-based and does not require a subscription.

This is all just off the top of my head right now. Undoubtedly more to come. In the meantime, join the fray!

Josh

Joshua Langman · June 8

(You can see some of my requests and complaints regarding ID here.)

Joshua Langman · June 8

Support for negative indents.

Support for mortising drop caps.

Support for hanging numbers for lists or notes in the margin.

Joshua Langman · June 8

Support for centering poetry on the longest line.

Generally, support for the kinds of things professional compositors do routinely that currently require workarounds because their tools weren't designed for them.

John Butler · June 8

An open, human-readable, Unicode text-based native file format like SILE, beneath an interface something like LyX. The file format independent of the tools to manipulate it.

Joshua Langman · June 8

A font menu that doesn't just show all the fonts on your system, but lets you specify what fonts are relevant to the document and shows just those.

OpenType features like all small caps accessible in the main interface.

Joshua Langman · June 8

A distinction between galleys and pages. The ability to view text as a long continuous galley or as a series of made-up pages. The ability to write nuanced rules for breaking text into pages.

Joshua Langman · June 8

The ability to display a language-specific glyphs palette. For instance, if I am typesetting something in Norwegian, I would pull up the Norwegian "typecase" and get a curated selection of glyphs specific to that language.

Joshua Langman · June 8

A way to simulate the show-through from the other side of the printed leaf. Useful for checking backing up. Generally, more features that recognize and reflect the physicality of printed books.

Andreas Stötzner · June 8

Joshua Langman said:

The ability to display a language-specific glyphs palette. For instance, if I am typesetting something in Norwegian, I would pull up the Norwegian "typecase" and get a curated selection of glyphs specific to that language.

I guess you mean character set by “glyphs palette”.

The functionality you describe I’d rather see met by a new generation of keyboards. Because fiddling about in glyph palettes (or character selection tool windows – the same thing) is neither productive nor user-friendly.

I imagine a keyboard which offers a) one-klick selection of Norwegian, Spanish, Urdu, Mandarin, Devanagari, Frisian, Bulgarian … you name it; b) keys which instantly display all the relevant characters for a chosen language/orthography.

Joshua Langman · June 8

A way to specify a cascading sequence of fallback fonts for missing characters: If a character is not supported in the text font, use the character from font A; if it's not in font A, use font B … with custom sizing and alignment for each fallback font. Also, the ability to specify fonts for specific characters: primes from font X, angle brackets from font Y. The ability to save such a "composite font" for use across documents.

Alignment options for verse: (1) center on longest line; (2) center on average line length; (3) center on median line length …

Built-in support for the niceties required by common style guides. For instance, how is it that the most widely used professional typesetting software in the world cannot break URLs according to Chicago style? (I'm rather proud of my approach to this, but all GREP-based methods, including mine, are imperfect.)

The ability to recognize figure calls etc in the text to assist the typesetter in ensuring that figures are placed appropriately.

Are there any software engineers on here? I do not have this skill, but if someone who does wants to pursue making a new piece of software, I would very seriously consider teaming up with them and tackling this for real.

Joshua Langman · June 8

A way to build the placement of text on the page into a paragraph style. So, for instance, chapter-opening sinkage could be a property of the first-par style or the chapter title style and would not require resizing the text frame.

A built-in understanding of constructs like parts, chapters, sections, so the software could accept instructions like "chapters begin recto only" or "chapter opening drops to fifth text line."

Marc Foley · June 9

I've been working on my dream layout application for the past year. It's based on baseline and Swiss grids from the start. You have the ability to define the body style and it will generate headings, captions etc based on the baseline grid.

I too am largely skeptical of AI. However, my app does use LLMs to populate premade templates if users want to.

I've been careful when creating the file format so developers will easily be able to programatically create documents.

I've decided to keep it browser based since I eventually want it to be a collaborative editor like Figma.

ME and Chinese is supported from the start since my app uses Harfbuzz.

Output is currently just pdf.

I'm still a considerable way off a v1.0.0 but I'm getting closish to have a working MVP.

@Joshua Langman I may reach out to you at some point. The typographic features you're after may be a bit too intense for my 80% product but we can see.

Image: https://us.v-cdn.net/5019405/uploads/editor/7j/g46uggyvlwlk.png

alerque · June 9

SILE (and sometimes LaTeX, Typst, and other FOSS) developer here.

It would be very easy to do *some* things better than InDesign, but bringing up an all new GUI project to the minimum breadth of features to viably use as a replacement is quite an ask. Not impossible, but a big bite.

I've done quite a bit of thinking about how programmatic typesetting engines (LaTeX, SILE, Typst, Speedata, etc.) could interface better with designer-friendly GUIs. One of the big overhauls I'm working on for SILE (targeted at v0.16.0) is organizing the internals of frames, fonts, and language in less of an ad-hoc way that is only friendly to direct code access and more of a structured module registry with a regular predictable API that would be much easier to eventually bolt a GUI onto.

On the other hand, I also think your approach of a "do everything" app won't be the best plan. I would separate concerns a bit through the workflow so that the on disk file format is one thing, the rules controlling the typesetting engine behavior are another, the interface(s) used to edit the above two things are another, the actual build process is another, and finally tooling for the review process is another. That isn't to say one GUI couldn't eventually wrap all of those, but I think tackling them as separate problems with an eventual way to control the end-to-end workflow is more realistic.

As a FOSS developer mostly working on this in spare time (with some of my day-job involving actual book publishing, hence the interest) I can say that it would probably take at least one fill time and a couple part time people to really make such a project even get off the ground, but there is *so much room for improvement* left on the table by all existing workflows, both commercial and open source.

In my mind one of the major problems in publishing is the non-synchronous stages that a manuscript currently forced to go through where assorted writers, editors, typesetters, designers, and producers are all isolated both in time and tooling. My goal is to have a whole ecosystem of tooling so that everybody has access to tooling that suites their role that also interacts with the whole process in a way that the project can stay flexible. If the author spots a typo after the book is typeset and the cover designed, they should be able to fix it in the same software they did the initial authoring in, and that change should easily propagate the the final production files and the resulting changes should be trackable and reviewable from the perspective of each role with no extra work involved or redoing any steps of their workflow from scratch.

alerque · June 9

Followup ...

My vision for what needs to happen in the typesetting & publishing space as far as GUI's should work is much more akin to what Graphite is doing for non-destructive editing of graphics. Re-inventing a better InDesign or Quark is not just as a GUI editor is not of that much interest to me. I don't just want a new GUI to be a better Scribus that could actually challenge InDesign. I would like something more like Graphite that completely changes the paradigm so that GUI typesetting can play nice with also editing the typesetting process as code and be reproducible/reusable/editable even while the inputs keep changing.

pereelmagne · June 9

A sophisticated hyphenation engine.

(Emoji of a person dacing shaking arms and crying of agreement.)

As of now, in theory, we can install Hunspell packages for languages not included in the default installation. Actually, trying to do so nullifies the whole spellchecking feature.

Joshua Langman · June 9

Many thanks to Marc, alerque, and others for your thoughtful comments and perspectives. I so appreciate your insight. Keep it coming.

Alerque — I'm not sure about allowing an author to tweak the production files for a book. There are reasons that authors are seldom allowed access to those files. But I'd be more than happy to discuss and perhaps be persuaded.

In the meantime, I continue …

A way to sort fonts by support for a given character. Enter a codepoint to view all fonts on the system that support it.

alerque · June 9

A way to sort fonts by support for a given character. Enter a codepoint to view all fonts on the system that support it.

I have two tools in my toolbox that do this, one is part of fontconfig, the other is distributed in TeXLive


$ fc-list :charset=1F4F9
/usr/share/fonts/TTF/Symbola.ttf: Symbola:style=Regular
/usr/share/fonts/joypixels/JoyPixels.ttf: JoyPixels:style=Regular
/usr/share/fonts/noto/NotoSansSymbols2-Regular.ttf: Noto Sans Symbols 2:style=Regular
/usr/share/fonts/OTF/Symbola.otf: Symbola:style=Regular
/home/caleb/.local/share/fonts/TTF/NotoColorEmoji.ttf: Noto Color Emoji:style=Regular

$ albatross U+1F4F9
        __ __           __
.---.-.|  |  |--.---.-.|  |_.----.-----.-----.-----.
|  _  ||  |  _  |  _  ||   _|   _|  _  |__ --|__ --|
|___._||__|_____|___._||____|__| |_____|_____|_____|

                    Unicode glyph with code points [1F4F9]
                         mapping to [📹] (AND search)
┌─────────────────────────────────────────────────────────────────────────────┐
│ Font name                                                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│ JoyPixels                                                                   │
│ Noto Color Emoji                                                            │
│ Noto Sans Symbols 2 Regular                                                 │
│ Symbola                                                                     │
└─────────────────────────────────────────────────────────────────────────────┘

Of course you'll say you aren't looking for a CLI tool, you want it to be right at your finger tips in a GUI. Well I can make a GUI that does just that, or better yet add it into some open source GUI that already handles font browsing and would mix and match with other purposes. And yes, it could go in a typesetting GUI too, but you're quickly approaching the reason all-purpose GUIs grow into monstrosities: the tools you consider handy and want at your finger tips are useless clutter to the next guy.

Joshua Langman · June 9

The ability to substitute one character/glyph for another, without affecting the underlying text encoding. The ability to include this surface-level substitution in a paragraph style. This feature alone would be invaluable. One of the largest limitations of GREP styles is that they cannot swap one codepoint for another.

The ability to define a span of text and rotate or mirror it without breaking it out into a separate text frame.

@mwichary— This thread seems like something you might be interested in. Care to join us? (We haven't properly met, but I'm a fan of your work.)

@alerque — it's not necessarily that I want to see a UI with lots of buttons and icons for all of these functions. I could be very happy with a sort of hybrid UI / command line / tagging interface. But I would need the syntax to be typographer-friendly and maybe display a WYSIWYG preview of whatever is going on in the code. Your screenshot scares me. Book designers traditionally think in terms of drafting table, ruler, T-square, pica pole, not code.

Dream big: your ideal composition / typesetting software

Comments

Categories