How do I force the use of base-14 fonts?

[RamKromberg]

What do I need to do to make sure this doesn't use Helvetica (or a substitute) if it happens to be available on the system but instead avoids embedding any fonts into the pdf:

\begin[class=plain,papersize=a4]{document}
\language[main=en]
\font[family=Helvetica]

this is a test.

\end{document}

I've considered using Helvetica Neue LT Std and write a script that manually removes the font object and forces the use of helv... But I figured it's best I'd ask here first instead.

Thanks

[Omikhleia]

I don't think we can.

Default PDF generation is done by the libtexpdf outputter, which invokes (hence the name), via a Lua-C bridge/wrapper, the libtexpdf library.

The latter was extracted from TeX's dvipdfmx software.

It might have ways to disable embedding, but it's not exposed via our wrappers.

Note that even if there would be a way to do it (digging deep into the libtexpdf / dvipdfmx code base...), this would nevertheless make the file non compliant with ISO standards, which is the reason why dvipdfmx considers non-embedding to be deprecated:

dvipdfmx always converts input encodings to CIDs and then uses Identity CMaps in the output PDF. However, ISO 32000‐1:2008 describes as

The Identity‐H and Identity‐V CMaps shall not be used with a non‐embedded font. Only standardized character sets may be used.

which had never appeared in Adobe’s PDF References. This makes all PDF files generated by dvipdfmx with non‐embedded CID‐keyed fonts non‐compliant to the ISO standards.

In other terms, besides non being trivial, it's probably a bad idea, not worth the effort?

Other PDF libraries could be supported by SILE, such as cairo or podofo - but they were only experimented long ago and are not actively maintained. The outputters and wrappers lack a whole lot of features, so this is not an option either in the current state of art.

EDIT: Of course, if someone has the guts and skills to revive the cairo or podofo outputters...

[RamKromberg]

which is the reason why dvipdfmx considers non-embedding to be deprecated

I'm not sure about pdf 1.7 but in 2.0 it's certainly not the case seeing how the PDF 2.0 examples specifically made use of non-embedded fonts: https://github.com/pdf-association/pdf20examples https://github.com/pdf-association/pdf20examples/blob/master/pdf20-utf8-test.pdf

But yeah. Seems it will probably take another outputter. Oh well. Thanks anyhow.

[alerque]

I'm not quite sure what you are after here. If you're worried about the use of a specific font, use a FONTCONFIG_FILE environment variable and setup your font substitution the way you want it to either use or avoid a specific font when requested by name in a document.

[RamKromberg]

I was asking about putting together pdfs without embedding the font by using one of the standard base 14 fonts: https://appligent.com/what-are-the-base-14-fonts/

pdfLaTeX defaults/ed to that behavior (much to the ire of some publishers) so I was hoping SILE can turn it on as it didn't work right out of the box. However, I was pointed out that's not possible due to some technical issues with dvipdfmx.

Anyhow, I'm just doing some early "window shopping" for a typesetting system with near-direct PDF access to satisfy some very narrow use-cases concerning technical documents. Nothing worth anyone's time and effort really so there's really no need to change anything in SILE.

[alerque]

Okay, I'm tracking I think. So you want to do exactly the opposite of what publishers recommend and is the default libtexpdf behavior? It's probably doable with some small toggles in the libtexpdf source code to set some flag, but I'll be honest: I don't have the time or interest in rooting out what it is because I don't want that outcome in my PDFs nor do I think it would be a good idea to enable in general. That being said if you want too root around a little bit in the libtexpdf source and figure out what to twiddle and want to set that up as an optional setting for the PDF backend I'd be happy to facilitate it getting merged. If pdftotex used to do this then chances are the code is already there, something just needs to be enabled to use it.

[Omikhleia]

Anyhow, I'm just doing some early "window shopping" (...)

This is a stopper for me, or I'll be very vocal and aggressive.
Good bye.

[RamKromberg]

Nothing worth anyone's time and effort really so there's really no need to change anything in SILE.

So you want to do... It's probably doable... I don't have the time or interest...

Oh I fully agree it's just too niche to justify the effort for a publishing-grade, print-first typesetter like SILE which is why I said as much. Only reason I asked is because I couldn't figure out how to do it and was wondering if it happens to be just some undocumented feature or something absolutely trivial for a maintainer to turn on. As that's clearly not the case, there's nothing for me to say or do.

Anyways, I kept the discussion open in case someone drops in with "oh you just toggle this and it works" but seeing how it's just wasting people's time I'll close it down. Still, if I ever get the itch and manage to figure out how to do it, I'll be sure to take you up on that offer when submitting the pull request ;)

Thanks.