View Single Post
Old 06-03-2020, 02:03 PM   #80
mdp
Wizard
mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.mdp ought to be getting tired of karma fortunes by now.
 
Posts: 1,481
Karma: 9010563
Join Date: Jul 2013
Device: none
Quote:
Originally Posted by pdurrant View Post
We know how the colour filter is overlayed on the 300dpi eInk display. See this post (in this thread!)
There must be a misunderstanding here pdurrant: the matter I am discussing there is not «how the colour filter is overlayed» on the display. You must have seen the picture I have taken, edited and published at post #71: it is taken from that video - I have seen it.

User Yoko22 has stated «if the resolution would be a problem due to the colors wouldn't we see it in the different video online?»
to which the direct answer would be that you need very clear pictures of details to see that.
Those would also reveal «how [rendering] is engineered». This does not reduce to knowing how the filter is made. It has all to do with how the filter is used: what do the rendering algorithms do to make that filter part of the "rendering with colours" goal.

The problem (which is complex and I am taking bits and pieces in this post) is evident by the expressions that Kozlowski has used in his article, such as «PDF rendering engines will display PDF files as an image [at 100 PPI], because that is basically what they are». Kozlowski tries to makes it light for his readers, and does not stick to the maxim of not oversimplifying. His razor is not the redundancy trimmer that would come from Occam; it is more related to Eugene (in "Be careful with that axe Eugene!"). PDF rendering engines of course do translate data into an image, because an image is what goes into a display: but such an image is originally made of at least raster and vector, which require different treatment. It may make sense that raster is assumed as in-colour and rendered as low-res, but the same is not valid for vector - like text -, though not all vector, because it may be flattened to anti-aliased black, or it may be rendered as low-res when in colour, or it may be tinted with a trick like the one I drafted at post #80. Many paths are open, it is not clear how the renderer works, how it interacts with other renderers at different software layers etc. Results must be seen. Just seeing how the hardware is done does not help.

Last edited by mdp; 06-03-2020 at 02:06 PM.
mdp is offline   Reply With Quote