Can't get exact CMYK in typst-generated PDF

[pantlmn]

When I use #barcode("github.com", "QRCode", options: (fg-color: cmyk(0%,0%,0%,100%)), I get in PDF with composite CMYK(71%, 68%, 64%, 73%).

How can I generate pure grayscale QR in PDF with CMYK(0%,0%,0%,100%)?

[YDX-2147483647]

Because tiaoma uses zint to generate an SVG, but the SVG standard only supports RGB colors.

zint-wasi/zint-typst-plugin/src/lib.rs

Lines 19 to 26 in db4123c

	#[wasm_func]
	pub fn gen_with_options(options: &[u8], text: &[u8]) -> Result<Vec<u8>> {
	let options: Options = ciborium::from_reader(options)?;
	let text = std::str::from_utf8(text).expect("non-utf8 string"); // bytes(data) always creates a utf8 slice
	let symbol = Symbol::new(&options);
	let svg = symbol.encode_svg(text, 0, 0)?;
	Ok(svg.into_bytes())
	}

According to linebender/resvg#766 posted in 2024, rendering SVG files with CMYK colorspace is not possible at present, and probably will not be possible in the next 3-5 years, if ever.

(Copied from the forum)

[Enter-tainer]

Hi @YDX-2147483647 thank you for your explaination!

Because tiaoma uses zint to generate an SVG, but the SVG standard only supports RGB colors.

One possible way is that we can let zint emit draw calls, and we can draw these elements using typst's primitive.

[Caellian]

we can draw these elements using typst's primitive.

Yeah, 0.3.0 0.4.0 will simply make WASM produce shape info and draw that from typst, and forward stylistic attributes like color.

According to linebender/resvg#766 posted in 2024, rendering SVG files with CMYK colorspace is not possible at present.

We currently don't even pass CMYK to zint. We convert all colors into RGB HEX format on typst side before forwarding them to zint which strictly generates SVGs with HEX colors in output as well. This is bad because RGB HEX color space is probably the smallest one.

In 0.3.0, we'll likely just draw rect/circle/text primitives from typst directly - this means that bg/fg color values will be directly forwarded to typst functions. This means HRT will support properties that aren't part of SVG spec either, but are otherwise supported by typst.

It's a bit stuck for now because I started swerving towards some features that aren't strictly needed. I'll be done by Christmas :)

All that being said, cmyk(0%,0%,0%,100%) should produce a black HEX color, so I don't get what part of cmyk(0%,0%,0%,100%).to-hex() -> WASM -> zint -> SVG -> typst fails and why.

[pantlmn]

we can draw these elements using typst's primitive.

Yes, and here the code I wrote to do this
https://forum.typst.app/t/qr-in-real-cmyk-grayscale/6894/7?u=pantlmn

#import "@preview/tiaoma:0.3.0" : qrcode
#let black_cmyk_qrcode(text, width: 1.5cm, color: cmyk(0%, 0%, 0%, 100%)) = {
  let svg-bytes = qrcode(text).source
  let qr_path = str(svg-bytes).match(regex("<path d=\"([^\"]*)")).captures.at(0) // get the path part of code from SVG
  let qr_rectangles_text = qr_path.matches(regex("M(\d+) (\d+)h(\d+)v(\d+)h-\d+Z"))
  let qr_rectangles_coord = ()
  for qr in qr_rectangles_text {
    qr_rectangles_coord.push(("x", "y", "width", "height").zip(qr.captures.map(x => int(x))).to-dict())
  }
  let tiles = calc.max(..qr_rectangles_coord.map(x => (x.x + x.width)))
  let tile_size = width/tiles
  rect(width:width, height: width, inset: 0mm, stroke: 0pt,
    {
    for r in qr_rectangles_coord {
        place(dx: r.x*tile_size, dy: r.y*tile_size, rect(height: r.height*tile_size, width: r.width*tile_size, fill: color))
    }}
  )
}

[Caellian]

As @YDX-2147483647 pointed out in the thread, cmyk(0%,0%,0%,100%).to-hex() produces #221f2 in typst, which is where this fails. (Thank you) So this isn't our issue, and wouldn't be resolved even by 0.4.0 - though I'll link it anyway so you get notified.

I looked into produced PDF postscript for #polygon(color: cmyk(0%,0%,0%,100%), ...), and even though it uses 0 0 0 1 K, the viewer in VSCode still showed the same gray for me. So even drawing shapes from typst wouldn't fix this problem - depending on what viewer you're using.

After googling/ChatGPT-ing a bit, I found the solution to your problem: cmyk(50%, 50%, 50%, 100%).to_hex() produces #000001, which is closest I was able to get to pure black. CMYK is for printing, and screen readers (including typst to-hex) show the color as it will approximately look when printed. See wikipedia article on "Rich black" for details.

[pantlmn]

Once again, the problem is not about showing CMYK on screen, it's about making proper file for printing house, getting image properly printed with 4 colors.
I use typst to make file of a book which will be printed in 1000 copies, with color images. So I need to have the file where black QR codes are cmyk(0%,0%,0%,100%).

On the screen cmyk(0%,0%,0%,100%), cmyk(50%,50%,50%,100%), rgb(0,0,0) look the same, but for 4-color printing they are different. Printing with all 4 colors a small QR code will make total mess — small shifts of color layers will fill the white space between black ones.

[Caellian]

So producing shapes like #polygon(color: cmyk(0%,0%,0%,100%), ...) which result in postscript that actually uses CMYK will solve the issue?

Out of curiosity and lack of experience: Does #221f2 look washed out when printed? Does #000001 actually use all 4 colors or the printer driver turns it into K?

[pantlmn]

So producing shapes like #polygon(color: cmyk(0%,0%,0%,100%), ...) which result in postscript that actually uses CMYK will solve the issue?

Yes, it will.

or the printer driver turns it into K?

I think it depends on the printer driver, but I was making PDF for big offset printing machines — tiny shifts of color layers will make it look washed out. Adobe Acrobat shows this as an error at prepress test, and the printing house will just reject this file.