Why don't we use the same syntax colouring as the editor?

[PeterWone]

Paper is white

Many people use a dark theme. If you simply change the background colour from black to white (or transparent) the contrast ratios are inappropriate and the colour scheme is pale and washed out and looks completely different. Theoretically you could write a transformation to adjust the colours but you would have to solve 2 n non-linear equations in 2 n variables to preserve relative hue and saturation, where n is the number of language part styles.

It's not supported by VS Code

For printing you need to pass a big string containing source code to a function that parses it to identify the language parts, then marks it up as HTML with the language parts wrapped in spans applying CSS classes so we can apply a colour scheme. That's what highlightjs does for us. We pass source code and it returns HTML ready for a stylesheet.

VS Code does not export its syntax colouring logic in a form we can use. It works by callbacks each of which processes a language part. It's done like this for performance, so that it only has to process the code that's in the visible part of the screen. Due to the way syntax colouring is done by editor callbacks there isn't a single coherent CSS stylesheet resource.

Could we ask for support from the VS Code team?

They won't even put something on the backlog without 20 upvotes for the issue within 60 days of the issue opening. This won't happen without widespread support or a coordinated effort. Printing is too niche for that kind of support.

We asked for help putting "Print" in the File menu five years ago. It hasn't happened. We asked for help getting a reference to the internal Markdown rendering pipeline too, and they were equally unresponsive (we found an unsupported hack that works).

So emulate the editor with a tall viewport

If that's as easy as it sounds we can expect a PR soon.

and use the callbacks to compile a stylesheet

The documentation is thin and the API is designed to support the editor receiving information (from a language server) not handing it out. It would be a big job and probably impossible without the VS Code team providing a new API.

But, but, but...

If you think we're wrong about this the best counterargument is a working PR, which will be very warmly received and integrated as soon as possible provided that it also addresses the unsuitability of dark themes.

We'd use the editor colour scheme if we could. That was the original plan, and it's no fun having to refuse every time someone asks for it.

What about mapping editor colour schemes to near match highlightjs schemes?

That would work, but only sometimes. It wouldn't work for schemes added by extensions, and not all the baked in schemes have direct equivalents. Inconsistent success would produce an endless stream of unhappy users, and someone would have to maintain the mappings forever.

[Evian-Zhang]

Come across this excellent extension when browsing vscode#5953, thank you for your work!

Since vscode has introduced its web version, I tried to use the browser's printing button on the vscode workspace web page, and it turns out that we CAN print the same syntax colouring as the editor if we are using the web. However, it still lacks customized uploaded font, so we cannot create a 100% same pdf as it looks in the vscode application.

I am not fully aware of how vscode differs in application mode and web mode, and I wonder if we can leverage some of steps how web version does printing to print a 100% same pdf as what it looks in application?

[PeterWone]

The Print extension uses an embedded webserver to render the base document and supporting resources (CSS, images, diagrams etc). It is flat out impossible to do this in the web version; I cannot create a node webserver.

The solution is to separate them and have a web-print extension pass the document to an external webserver. Is this technically possible? Yes. Are we interested in paying for the server and bandwidth for a free service? No. Do we intend to build this? Yes. But it won't be free. It can't be free. But it also won't be expensive. Provided users pay enough to cover cost, funding scales with load.

[Evian-Zhang]

Thank you for your reply. Sorry for the ambiguity, but what I mean is not directly migrating current print extension implementation towards web edition. Instead, I wonder if we could leverage the browser-builtin "print" functionality on the vscode web edition. The print button on the browser does print the same pdf as we can view in the vscode web. However, since the vscode web does not support customizing fonts, we cannot directly use this solution.

[PeterWone]

If you do that you'll print what's on the screen, not the whole document. It only renders a small portion of the document for performance reasons. If there was a way to get it to render the whole document I'd use it if only to silence the people who complain that I don't use VS Code's syntax colours. I have wondered whether I could host the web version in an IFRAME and make it a very tall window but I haven't tried yet.

[steveculshaw]

One comment ... use of a dark theme.

I'm 60+, and I find the dark theme a big strain on my eyesight ...
After even a short time looking at a page of text in dark mode, my vision is left with "ghost lines" for a minute or two

I've mentioned this to my other coder friends, and they've got similar experiences