Support for PNG output identical to PDF
authorDavid Decotigny <david@decotigny.fr>
Sun, 5 Sep 2010 17:06:37 +0000 (19:06 +0200)
committerDavid Decotigny <david@decotigny.fr>
Sun, 5 Sep 2010 17:06:37 +0000 (19:06 +0200)
commit524c7baca5ccaf33128a9f1624b04a074e91c11b
treef619b160d147ffa30a43f7a8c2f223559eddf761
parentbbce200910ae42ef498094a3e81ee7cc6a76501d
Support for PNG output identical to PDF

This has not been so easy because:
 - we need some kind of scaling because by default 1 pt in PDF = 1 px
   in PNG... And we would prefer to have 1 pt in PDF = 300/72. px
   (assuming PNG is 300dpi)
 - we cannot call ctx.scale() before rendering the index because pango
   takes the transformation matrix into account when it chooses the
   font metrics. So with ctx.scale(), we could have the actual font
   metrics different from those computed in
   precompute_index_occupation() { which is called on a PDF surface by
   SinglePageRenderer::render() }.
 - we cannot render to a 72dpi vector surface (eg. PDF) and then
   project it with a scaling factor onto a 300 DPI PNG surface,
   because the result is ugly (pixelized)
 - we cannot push_group()/post_group().set_matrix(xx=factor,
   yy=factor=)/set_source() for the same reasons (pixelized)

So the solution we adopt is to trick pango into believing it is
rendering without any scale factor, which for us corresponds to a
72dpi resolution, and which for it corresponds to a 96 dpi cairo
resolution (see sources): this should always generate the same font
metrics as precompute_index_occupation() did. Then we tell it that the
cairo resolution, instead of being 96dpi as it assumes, is
96*desired_resolution/72. This is what this patch does.

One more note: we don't use an ImageSurface cairo surface for PNG
output because, for some other reason, it leads to different font
metrics. So, for PNG, we do use a PDF cairo surface !...
ocitysmap2/__init__.py
ocitysmap2/index/render.py
ocitysmap2/renderers.py