X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/d7e54aeb2f09986a9062d5147f6f85448bb3a843..f36514d27f4975fcb38926f53b557c680cbb38fb:/doc/bugs/svg_and_pdf_conversion_fails.mdwn

diff --git a/doc/bugs/svg_and_pdf_conversion_fails.mdwn b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
index 41637c51d..c159da5ad 100644
--- a/doc/bugs/svg_and_pdf_conversion_fails.mdwn
+++ b/doc/bugs/svg_and_pdf_conversion_fails.mdwn
@@ -20,3 +20,26 @@ that needs special care or breaks something i don't use; this way, my patches
 should be safe for inclusion.
 
 --[[chrysn]]
+
+> update 2014-06-29: the patch still applies and fixes the issue. in the
+> meantime, i noticed that the desired effect doesn't happen when no explicit
+> size is set. as scalable graphics don't necessarily have a natural size
+> anyway, i don't consider that a showstopper. --[[chrysn]]
+
+>> This all looks good in principle, but I would like to do a more detailed
+>> review, and test it with "real ImageMagick" in case its behaviour differs
+>> from GraphicsMagick.
+>>
+>> An automated regression test for the desired behaviour in `t/` would
+>> be great. There are SVGs and PNGs in the docwiki already; there are no
+>> JPEGs or PDFs, but perhaps you could add a trivially small example
+>> of each to `t/`? Imitating `t/tag.t` or `t/trail.t`, and skipping the
+>> test if the required modules are missing like `t/podcast.t` does,
+>> seems like it would work best.
+>>
+>> I agree that everything not in an interoperable web format should be
+>> converted to PNG when it's scaled down, but yes, that's more likely
+>> to be a breaking change, so it seems best to do that as a separate
+>> branch. In practice I think this means JPEG -> JPEG and everything
+>> else -> PNG, since JPEG is commonly used for photos and photo-like
+>> images that don't compress well under lossless compression. --[[smcv]]