31–40 of 172 posts
Earlier quoted context omitted.
Probably because pdf.js is implemented using so it's basically like printing screenshots of the PDF
They have been working on SVG backend for quite a while to get real vector printing, still not done.
Earlier quoted context omitted.
They have been working on SVG backend for quite a while to get real vector printing, still not done.
I am not surprised, given the poor SVG support of Firefox (and browsers in general). Also there are gradient types that PDF supports but SVG doesn't. I am also not sure why they would need to go through SVG for printing.
Canvas is just a bitmap so when printing pdf.js renders to a certain dpi canvas which I believe is less than 300 dpi (150?) which even still uses huge memory and ends up with fuzzy text.
You don't want bitmaps going to printer for text and line art, you want vector so it can come out at 600+ dpi while using minimal memory.
P.S.: because subpixel effectively gives you 3x horizontal resolution, it looks terrible to still fit to a pixel grid horizontally. Check the Anti-grain geometry article on font rendering for more cool font rendering bits, I recall it being very interesting.
Earlier quoted context omitted.
I am not surprised, given the poor SVG support of Firefox (and browsers in general). Also there are gradient types that PDF supports but SVG doesn't. I am also not sure why they would need to go through SVG for printing.
SVG is the only way to get vector printing through a browser currently unless its just normal html/css which isn't enough to render a pdf. Canvas is just a bitmap so when printing pdf.js renders to a certain dpi canvas which I believe is less than 300 dpi (150?) which even still uses huge memory and ends up with fuzzy text. You don't want bitmaps going to printer for text and line art, you want vector so it can come…
This is what seems weird. Why is that? Also it's not like most printer drivers don't need to convert it back to ps or pdf before printing.
Related undesired complexities/heterogeneities I encountered while implementing a simple text drawing API on top of various libraries (cf. "Pain points", near the bottom):
https://github.com/jeffhain/jolikit/blob/master/README-BWD.m...
Another pain point on text AA: Many renderers mix up colorspaces on antialiasing. For example freetype assumes a linear colorspace when calculating the antialiased bitmap but AFAIK both GTK and QT apply it directly on sRGB without any adjusting. The result is apparently thickened fonts when displayed black on white and thinned fonts when displayed white on black. Edit: Some background can be read on [0]. [0] https://…
With high density monitors on the rise we should get rid of LCD (RGB rainbows) anti alias as its really just a hack.
Also regarding hiDPI: I know that you just want to get rid of subpixel antialiasing but you really don't want to get rid of antialiasing in general. It's not really an issue with typefaces, but non-antialiased high-frequency patterns can easily generate unwanted Moiré patterns on you display regardless how high is your display resolution.
Speaking of mercy, I wish Apple had disabled it only on hidpi displays and chosen a longer deprecation window for normal displays.
I prefer keeping displays at a distance slightly longer than my arm. This completely hides the slight blur of subpixel antialiasing.
Now a 1440p has significantly degraded text rendering (even though other graphics look great) and if you want to use an external display, it must be 4K or 5K to not get a blurry, thin mess.
Earlier quoted context omitted.
SVG is the only way to get vector printing through a browser currently unless its just normal html/css which isn't enough to render a pdf. Canvas is just a bitmap so when printing pdf.js renders to a certain dpi canvas which I believe is less than 300 dpi (150?) which even still uses huge memory and ends up with fuzzy text. You don't want bitmaps going to printer for text and line art, you want vector so it can come…
> SVG is the only way to get vector printing through a browser currently This is what seems weird. Why is that? Also it's not like most printer drivers don't need to convert it back to ps or pdf before printing.
SVG is turned into the appropriate PS/PDF vector drawing command by the browser print engine, canvas just gets sent as a bitmap in the printer language since that all that's left.
I believe pdf.js incorporated and modified https://github.com/gliffy/canvas2svg which implements the canvas api but instead creates an SVG dom.
Earlier quoted context omitted.
> SVG is the only way to get vector printing through a browser currently This is what seems weird. Why is that? Also it's not like most printer drivers don't need to convert it back to ps or pdf before printing.
You can't convert a bitmap back into vectors (well maybe image recognition of some sort). Once you render to canvas its a bitmap and stays that way all the way to printer. SVG is turned into the appropriate PS/PDF vector drawing command by the browser print engine, canvas just gets sent as a bitmap in the printer language since that all that's left. I believe pdf.js incorporated and modified https://github.com/gliffy…