sub A [one two three] by [X Y Z] ;

where the substitution output would be as per:

 A 1 => X
 A 2 => Y
 A 3 => Z

?

As expressed above, the syntax isn't valid.  Is there a similar expression that accomplish the intended substitution?

thanks!

Since the letter shape of Alpha and Alphatonos looks identical in Monotonic Greek (and it is true for double encoded unicase fonts), I would like to encode all ~tonos versions to their base letters. Is it a good idea? If so, is my encoding map correct?

Alpha			0391 03B1 0386 03AC	← Alphatonos
Beta			0392 03B2
Gamma			0393 03B3
Delta			0394 03B4
Epsilon			0395 03B5 0388 03AD	← Epsilontonos
Zeta			0396 03B6
Eta			0397 03B7 0389 03AE	← Etatonos
Theta			0398 03B8
Iota			0399 03B9 038A 03AF	← Iotatonos
Iotadieresis		03AA 03CA 0390		← iotadieresistonos
Kappa			039A 03BA
Lambda			039B 03BB
Mu			039C 03BC
Nu			039D 03BD
Xi			039E 03BE
Omicron			039F 03BF 038C 03CC	← Omicrontonos
Pi			03A0 03C0
Rho			03A1 03C1
Sigma			03A3 03C3 03C2		← sigmafinal
SigmaLunateSymbol	03F9 03F2
Tau			03A4 03C4
Upsilon			03A5 03C5 038E 03CD	← Upsilontonos
Upsilondieresis		03AB 03CB 03B0		← upsilondieresistonos
Phi			03A6 03C6
Chi			03A7 03C7
Psi			03A8 03C8
Omega			03A9 03C9 038F 03CE	← Omegatonos

Question 2 — suppress tonos in ccmp

Also, in the case when tonos is a separate symbol in the text, I would like to compose it in ccmp, but directly to Alpha glyph instead of Alphatonos (which is not presented in the font and is encoded in Alpha glyph now). Will this substitution break the source text if the user copy it or change the font?

script grek;
language dflt;
lookup ccmp_grek_1 {
	sub Alpha acutecomb by Alpha;
	sub Epsilon acutecomb by Epsilon;
	sub Eta acutecomb by Eta;
	sub Iota acutecomb by Iota;
	sub Omicron acutecomb by Omicron;
	sub Upsilon acutecomb by Upsilon;
	sub Omega acutecomb by Omega;
} ccmp_grek_1;

This started while I was writing academic papers. I could usually get acceptable PDFs, but having precise control exactly where it mattered most was always frustrating.

Most tools can produce PDFs, but once you compare layout precision, typography, usability, and long-term stability, the differences show quickly. Many workflows don’t provide satisfying results when you start measuring details closely.

I went through most of the usual XML-to-PDF stacks: DocBook with XSL-FO and HTML routes, DITA and DITA-OT pipelines, Apache FOP, Prince XML, Paged.js, Typefi-style systems, and a range of enterprise tools. I also spent time with TeX-based workflows. They are incredibly powerful and impressive, but in practice the complexity and friction often push people to admire them more than actually use them day to day.

Where things tend to break down is layout fidelity. Font rendering depends on ambiguous units or web-engine limits, styling has a steep learning curve, and many systems feel disconnected from traditional DTP practices.

After running into the same issues for years, I ended up building my own solution focused on predictable PDFs, stable pagination, and consistent typography. People coming from both the XML world and traditional tools like InDesign seem to feel comfortable with it, which was exactly the gap I was trying to explore.

1. hp2pk
2. pk2bdf
3. Import the BDF file into Fontographer 3
4. Run an autotrace feature.