Emoji export in PDF

[urban nexus]

Supporting color emoji in the PDF exporter.

Issue: https://github.com/typst/typst/issues/144
Background and implementation steps: https://github.com/typst/typst/issues/144#issuecomment-1846925843

@reef star

[urban nexus]

good news, @stone harbor is working on this now!

[fickle leaf]

Wow 🔥😱 it's going 🏃 to be 🐝 so great 💯👌 to finally 🍁 be 😹😹😹 able 💪 to use 😐🤔😴 emojis ⌚ in 🍝🥫 all 🧨 my 😘 papers

[mortal creek]

im too young for a stroke

[strange kettle]

And yer heear wee arezf,goien, ger,i eg

[urban nexus]

Merged: https://github.com/typst/typst/pull/3853 🎉

[fickle leaf]

Is this a complete implementation, or are there still missing features?

[urban nexus]

It is more or less complete. The only missing format is COLRv1, which is pretty new and almost universally unsupported.

[fickle leaf]

Presumably more relevant for html output

unless typst would translate them to type 3 fonts on the fly

[urban nexus]

HTML is easy, just do nothing and let the browser handle it

[timber wigeon]

Nice!

[urban nexus]

That's exactly what's happening with all formats now.

[timber wigeon]

I just saw the hacky workaround with Apple Color Emoji, I faced the exact same problem when implementing it for resvg 🙃

[fickle leaf]

okay, so the missing part would be the translation from colrv1 to type 3?

[urban nexus]

Ana spent more than a day trying to figure it out, but it's just not spec compliant whatever Apple is doing

[timber wigeon]

firstly it needs to be supported in ttf-parser

[urban nexus]

I saw that you wanted to take that on!

That's nice

[timber wigeon]

Yes, I tried loading Apple Color Emoji on Windows and the baseline isn't applied

For what it's worth, neither do the harfbuzz folks, so we are good: https://github.com/harfbuzz/harfbuzz/issues/2679#issuecomment-1345595425

[urban nexus]

I didn't know you implemented emoji support in resvg. When did that happen?

[timber wigeon]

like a couple of days ago

[timber wigeon]

if I find the time 😬

[urban nexus]

what did you end up doing?

hah, we also do black foreground for COLR

sorry, but not gonna write multiple glyphs per glyphs just for that

I see. 0.128 * self.font_size

[timber wigeon]

I basically tried a couple of different font sizes and it seems like this value is pretty on spot

[urban nexus]

slightly different value than Ana picked

[timber wigeon]

but great that we have emoji support in Typst now!

[urban nexus]

so now it's supported by Typst and resvg, but not svg2pdf

[timber wigeon]

now I just need to steal the code for svg2pdf

[urban nexus]

we'd need that shared abstraction crate

[timber wigeon]

indeed :(

[urban nexus]

but Typst's implementation also makes use of the Frame infrastructure, so it's not exactly easily portable

Had I known that you worked on that, the two of you could have shared the pain of figuring out the transforms

wait, how did you handle SVG?

[timber wigeon]

haha sorry, maybe I should've mentioned it somewhere 😄 but it was pretty spontanous

[urban nexus]

The Typst code needs a hack to make the SVG unsized

with some string manipulation

[timber wigeon]

🤔 how so?

[urban nexus]

https://github.com/typst/typst/blob/4c8a8f122aa2326543f5d24962c79436506b1a55/crates/typst/src/text/font/color.rs#L197

you have access to resvg internals, so that might change things

we can't just group.children.push(Node::Group(Box::new(tree.root)));

[jaunty mesa]

Well, with "Noto Color Emoji" it looks complete, comparatively to a few PR commits before the merge, but the selection is kinda meh: https://github.com/typst/typst/pull/3853#issuecomment-2061616123.

[fickle leaf]

I doubt that's typst's fault

[timber wigeon]

mm maybe, not sure I understood why it's necessary, but maybe I also haven't tested it thoroughly

but it seems to work fine with Twitter Color Emoji

[jaunty mesa]

apple and their shenanigans...

[jaunty mesa]

the font is the same and the PDF viewer is the same. The only difference is that typst's pdf file is v1.7 and lualatex's is v1.5. I'm not sure if those 2 new minor versions changed the way the selection works, but other than that, it's typst's fault, or rather the difference is only because different compilers were used.

[urban nexus]

I think you're actually doing more or less the same thing. It's just not hacky if you don't have to do it on the string level.

[fickle leaf]

could you upload the pdf from typst and lualatex?

[timber wigeon]

maybe, although if you are using svg2pdf to render the glyph into an XObject, I think there shouldn't be anything cut off, so in theory it should be possible to just apply the transform to the XObject to get it in the rifht position? But maybe I'm missing something

maybe I can take a look if I find the time to do so

[urban nexus]

i think the problem was that the XObject did clip

[jaunty mesa]

I'll try compiling just the same bit, otherwise I'll cut the important page.

[timber wigeon]

okkk yes I think I see now, this is what I get when i render the extracted svg of a smiley with resvg

I think this mighy be a resvg bug though. The above picture is what I get with this SVG:

<svg xmlns="http://www.w3.org/2000/svg" id="glyph878">
    <g transform="translate(0 -6.75) translate(0,-1638.4) scale(56.888888888888886)">
        <circle fill="#FFCC4D" cx="18" cy="18" r="18"/>
        <path fill="#664500"
              d="M18 21c-3.623 0-6.027-.422-9-1-.679-.131-2 0-2 2 0 4 4.595 9 11 9 6.404 0 11-5 11-9 0-2-1.321-2.132-2-2-2.973.578-5.377 1-9 1z"/>
        <path fill="#FFF" d="M9 22s3 1 9 1 9-1 9-1-2 4-9 4-9-4-9-4z"/>
        <ellipse fill="#664500" cx="12" cy="13.5" rx="2.5" ry="3.5"/>
        <ellipse fill="#664500" cx="24" cy="13.5" rx="2.5" ry="3.5"/>
    </g>
</svg>

but if I remove the outermost g group, it looks like that:

ok no its not a bug... Chrome shows it the same

im sure there is something we can do against this though, at the latest when I port the code to svg2pdf I will have to figure it out, so I can just post here if I have a solution

[jaunty mesa]

Each time for some reason I need to compile something or rather re-compile some old document in latex, I get anxiety, because I think that either I forgot to install the texlive distro or that I get some errors and the document won't compile.

But thankfully for that document everything was local and I indeed have texlive installed, so latexmk -lualatex -shell-escape worked like a charm.

[fickle leaf]

in sumatra pdf I can't select the ones in the lualatex one at all

while selection works in the typst one

same in firefox

[jaunty mesa]

same with firefox

[fickle leaf]

I think it's just the hellscape of pdf compatibility

[jaunty mesa]

mhm

[fickle leaf]

as an aside, we need subsetting @timber wigeon 😂

[jaunty mesa]

well, at least the selection is always present in typst's version, so I guess that's the most important thing.

[fickle leaf]

1.68 MB for like five lines of text

[jaunty mesa]

1.68 MiB*

[fickle leaf]

the distinction is rarely important

and the former has one fewer letter

[jaunty mesa]

(I really gotta find time later to make a yet another script, which will change SI to IEC units in websites I use, so that I can relax more.)

[jaunty mesa]

that's just lazy talking in you.

[fickle leaf]

no, I just don't care very much

[jaunty mesa]

Yet you didn't omit the fractional part. Even if so, I just raise awareness that IEC exist, and that you shouldn't mix it with SI.

[green verge]

That deserves cost since you can selected emoji in typst 🚀 but not in lualatex

[jaunty mesa]

you can select some and in some PDF viewer

[timber wigeon]

Wait are you talking about the emojis? If so then subsetting wouldn’t help much there because for emojis we don’t embed the font anyway

[urban nexus]

there's a bunch of other text in that doc as well, including Chinese text, which is likely the cause of the size

[timber wigeon]

Ah makes sense

[jaunty mesa]

for lualatex it doesn't even list the font. And even if I can select it, it isn't copyable. so I guess latex sucks even more, despite being powerful and mature.

[stone harbor]

"fully embedded" here is a bit misleading, as type3 fonts are custom fonts (they are not embedded ttf files), so they are always considered "complete" but they actually are a subset of the original font (we just copy emoji glyphs from here into another format that pdf readers understand)

not sure if this explanation makes things clearer to you, but all you should know is that it is a subset of the original font despite what your pdf reader says

[fickle leaf]

Is it possible for typst to specify that it's a subset regardless?

So that it's not displayed that way

[stone harbor]

I think the only thing preventing that is the "0" in the "COLOR0" at the beginning of the font name, the spec says it should be only capital letters

it also only mentions type 1 and truetype fonts, so not sure it would work with type3 fonts

[fickle leaf]

you mean the end of the font name?

[stone harbor]

i mean the part that is circled

[jaunty mesa]

But then the phrase "for emojis we don't embed the font anyway" still is false? Because the font is embedded in some way and glyphs are selectable/copyable.

[stone harbor]

We embed part of the font (and after transforming it quite a lot), but not the original ttf file, I think that's what was meant with "we dont embed the font anyway"

[timber wigeon]

Yes maybe I should have been clearer, sorry

[jaunty mesa]

ok

[timber wigeon]

@stone harbor btw I just saw your message in quick-questions, in case you want to add COLRv1 as well, feel free to use this implementation I made which is a best-effort implementation to convert a COLRv1 glyph into a SVG file https://github.com/RazrFalcon/resvg/blob/master/crates/usvg/src/text/colr.rs. I think you could use this and treat it more or less the same as an SVG glyph. Maybe this helps, as there are quite a few things that are a bit tricky in terms of transform order and so on (and the API in ttf-parser could be improved too...). It's not perfect because a lot of things like conic gradients can't be represented directly in SVG, but it should work fine for like 99% of the cases 😄

[stone harbor]

cool, thanks a lot!

i will probably give it a look at some point, but it is not a priority right now as colorv1 emojis are still pretty new and not well supported in other softwares anyway

[timber wigeon]

oh yeah no worries, just wanted to point it out!

[craggy talon]

Does the current implementation not support SVG table, or I missed something?

seems svg export has color, but pdf doesn't

[timber wigeon]

works fine for me

maybe you're not running from main?

[craggy talon]

oh, I mistakenly thought this had already landed in 0.11.1. Thanks

I will try using main.

[timber wigeon]

@stone harbor would it be okay for you if I give the colrv1 thing a shot myself?

[stone harbor]

Yeah sure

[timber wigeon]

:D

still a few issues I need to look into but looks promising at least!

[timber wigeon]

and damn they make the PDF veeery big

[mortal creek]

That segoe laughing emoji literally dips lmao

[timber wigeon]

Yeah…

[strange kettle]

overall, it looks stunning

but definitely needs some compression then?

Can't 👏 wait 👏 to 👏 type 👏 my 👏 take-home 👏 message 👏 like 👏 this 👏 in 👏 my 👏 papers.

[timber wigeon]

Well I’m not sure how

The problem is that the 3d Emojis have like a billion different gradients

To emulate the 3d effect

And gradients are pretty big in pdf as you might already now

[fickle leaf]

With proper subsetting?

[fickle leaf]

Embed as WOFF?

[fickle leaf]

Baseline looks a bit inconsistent. But that could be issues with the fonts of course

[timber wigeon]

Emojis are embedded as pdf instructions

[timber wigeon]

Probably the font I think

[fickle leaf]

Do they have to be?

[timber wigeon]

Yeah

[fickle leaf]

Naive question: I know pdf uses deflate, but is the entire file compressed, or only parts of it?

I guess what I'm getting at is whether or not the emojis get compressed in the file

[timber wigeon]

The instructions get compressed

But not the gradients

As in the definition of gradients

I think pdf supports a feature where you can basically compress the whole file but I don’t think pdf writer supports that

[fickle leaf]

And they can't be?

Anyway a realistic document will presumably use fewer emojis than in your picture

[fickle leaf]

Are the gradients per font or per symbol?

Sorry for all the questions 😛

[timber wigeon]

Only with the above mentioned feature I think

[timber wigeon]

Per symbol

[timber wigeon]

Yeah that’s true haha but still

[fickle leaf]

Do symbols share gradients at all? Presumably there is some reuse

[stone harbor]

they should if two gradients are the same

[fickle leaf]

Should as in "should if the font designer did the reasonable thing"?

Or should as in "typst makes sure that's the case "

[stone harbor]

a bit of both 😛 the gradient needs to have the same representation on typst's side, so the font needs to re-use the exact same gradient (but it can be duplicated in the font file, as long as it is always the same, even if that wouldn't be very smart), and then typst can properly deduplicate it when exporting to pdf

[timber wigeon]

the problem is that I'm converting the colr fonts to svg basically

[stone harbor]

oh

[timber wigeon]

I dont think there will be reuse then, since each svg is converted separately by svg2pdf

[stone harbor]

yeah

[timber wigeon]

but yeah I mean these are details that can all be improved upon in the future 😄

[stone harbor]

maybe it would be worth to implement it using pdf instructions directly, instead of converting to svg and using svg2pdf?

[timber wigeon]

would be very trouble some I'm afraid

especially because Typst doesn't support gradients with opacities

which are used heavily

[fickle leaf]

Maybe that should be resolved first

[timber wigeon]

idk I mean I think it should be okay for now, it's not like anyone will include 200 emojis in their documents...

as I mentioned, it can always be optimized in the futuer

[fickle leaf]

👍

[fickle leaf]

I guess unless pdf-writer was smart enough to recognize duplicates

[timber wigeon]

that would have to happen at a different level of abstraction

and I hate Apple Preview for still not having fixed their annoying soft mask bug 😠

[fickle leaf]

Toasted emojis

[timber wigeon]

also let's not forget about this one who looks like it just got beaten 😂

[fickle leaf]

Apple preview just sounds bad in general

[timber wigeon]

(this one is in all viewers unfortunately. I'm not sure yet whether it's a ttf-parser bug or just a known limitation from how gradients are represented in SVG)

[strange kettle]

compression is the saving grace here because it's very compressible, we just need to... implement it.

Which is definitely easier said than done

[strange kettle]

that's cursed lmao

[urban nexus]

PDF object streams would likely not be that hard to support in pdf-writer

[timber wigeon]

I think so too

my only concern

is this

so I guess you can't just throw everything into a single object stream...

[fickle leaf]

Presumably that was more of a concern 20 years ago?

[timber wigeon]

who knows

I mean how old is Acrobat 6 😂

maybe I can sneakily ask on the Artifex Discord what mutool/ghostscript does

[fickle leaf]

2003

[fickle leaf]

Probably a good idea

[timber wigeon]

only after my exams though

[strange kettle]

good luck friend

[olive inlet]

If you reuse the exact same emoji does it incur the same costs?

[timber wigeon]

it shouldnt

[olive inlet]

awesome

So this definitely doesn't seem like that big a deal for most documents

[timber wigeon]

so looks like mupdf uses a limit of 256 objects per object strean

yeah that would be pretty ugly to implement...

[urban nexus]

@timber wigeon re #1208798893069045830 message: The position is top-left of the image, yes. As for how exactly the frame is positioned in a line of text, I'll have to defer to @stone harbor.

[timber wigeon]

no worries, I think I already figured it out! it seems to be the top left of the em box

[urban nexus]

btw, the first can be simplified to Point::zero()

yeah, that makes sense, since the frame is em-sized

[timber wigeon]

oh yeah, that was just for testing :p it wont stay zero

[urban nexus]

but the question is still where the baseline ends up

[timber wigeon]

yeah it's a bit tricky, but I think I figured it out

[urban nexus]

@timber wigeon is the COLRv1 stuff now also sorta duplicated across resvg and typst?

if yes, so much duplication across typst, svg2pdf, resvg, ... :/

[timber wigeon]

it's duplicated across resvg yes

it's not in svg2pdf and I don't plan on implementing it there for now

[timber wigeon]

yeah, but I mean there isn't really much I can do about it :( we don't have a COLRv1 rasterizer, and until we have a high-level pdf writer crate I also can't really deduplicate across svg2pdf

I mean if you dont want to accept the PR I understand, but I still think it's better to have some support (which honestly should work in 98% of the cases) than none^^

[urban nexus]

I didn't mean to imply that you could do anything about and I also don't plan to reject the PR. I fully agree that it's good to have and I'm grateful for your work on it. Sorry if that came across the wrong way. I'm just a little frustrated about the duplication and that we don't have any solution for it in sight.

[urban nexus]

what if usvg exposed an API to convert any color glyph to a Tree?

could be used across resvg, svg2pdf, and Typst

[timber wigeon]

not sure how happy RazrFalcon would be about having this

it's very specific after all...

[urban nexus]

isn't the point of usvg to make it easy to render an SVG?

this is part of it after all

[timber wigeon]

well yeah but COLR fonts aren't really SVG right? 😄 the only reason we even convert it into SVG is because it's the easiest option for now

[urban nexus]

wait, wouldn't (shouldn't?) usvg's Text::flattened() already do that essentially?

[urban nexus]

text is SVG ^^

[timber wigeon]

I think we are aneinander vorbeireden again 😂

the thing that is duplicated is the implementation of the conversion from COLRv1 to an svg file, right?

[urban nexus]

yeah

why not generate an svg file with just the glyph text in it and take its flattened group?

[timber wigeon]

now that sounds like a hack 😂 maybe it could work... but then we have to deal with fontdb stuff again

and make sure usvg selects the correct font

[urban nexus]

that'd be easy with the font provider

but yeah, it's a bit of a workaround

[timber wigeon]

I can try to look into it, but probably not today

[urban nexus]

as you prefer. maybe it's unnecessary and only more brittle and slower in the end. I wouldn't block the PR on this.

[timber wigeon]

I think it would be better to leave it for the future if that's okay 😄

as I said, there shouldn't be any issues in most cases

and at some point we can hopefully implement it properly

[urban nexus]

yeah, it's totally fine

we can revisit this when we're building a unified drawing crate

[patent sequoia]

as in for typst, or a general image processing crate?

[urban nexus]

primarily for typst, but maybe also general purpose? but not really image processing, more text & vector drawing with support for various output formats. a bit like cairo.

[strange kettle]

GUIs in Typst? yes please

But we would need an export to triangles + textures

[fickle leaf]

Sounds like a good idea eventually for preview purposes anyway

No?

Gpu accelerated rendering 🙂

[patent sequoia]

Give it layers

Or like

actually, is there external script invoke support?

[fickle leaf]

You mean shell escape?

[patent sequoia]

Probably.

[patent sequoia]

Someone requested generative AI integration and I think that's kind of silly since we don't need giant rat penis: typst edition, but I do think something like shell escape sounds nice

[fickle leaf]

You just destroyed part of @strange kettle's soul

[patent sequoia]

I'll do it again

[fickle leaf]

No there's no shell escape, but wasm plugins serve that purpose

[patent sequoia]

I think Discord's search really dislikes the threads in #contributors

so I can't conveniently search

but the reason I'm popping in here is to ask where there are plans to to use the platform specfic APIs for the color emojis since everybody implemented their own version

Apple has their own TTF extension, Google did theirs, and MS decided to work extra hard by making two color emoji standards (if I remember right)

And then there's the awful 3D emoji features mentioned earlier (I think)

[strange kettle]

||https://tenor.com/view/bring-it-on-kuzco-lama-gif-16822682||

try me

[urban nexus]

no plans to use platform APIs. Typst now mostly supports all of the color emoji formats without calling into platform APIs.