Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753180AbcKURos (ORCPT ); Mon, 21 Nov 2016 12:44:48 -0500 Received: from ms.lwn.net ([45.79.88.28]:35274 "EHLO ms.lwn.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbcKURor (ORCPT ); Mon, 21 Nov 2016 12:44:47 -0500 Date: Mon, 21 Nov 2016 10:44:44 -0700 From: Jonathan Corbet To: Mauro Carvalho Chehab Cc: Linux Doc Mailing List , Mauro Carvalho Chehab , Linux Kernel Mailing List , ksummit-discuss@lists.linuxfoundation.org, Sakari Ailus , Laurent Pinchart , Markus Heiser , Mauro Carvalho Chehab Subject: Re: [PATCH 0/9] Get rid of bitmap images Message-ID: <20161121104444.28862d80@lwn.net> In-Reply-To: References: Organization: LWN.net MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1518 Lines: 39 On Sun, 20 Nov 2016 14:08:31 -0200 Mauro Carvalho Chehab wrote: > The goal of this patch series is to get rid of PNG images, using either graphviz > or SVG for images. > > For old images generated with xfig, stored inside PDF, just convert them to SVG > and cleanup the images using inkscape. > > Other images need to be rewritten in SVG. > > The pipeline image is actually a graphviz diagram. So, use dot to convert it > to SVG. > > For now, I'm keeping the image conversion rules inside the > Documentation/media/Makefile. As we get other docs using images, > the best would be to move those rules to Documentation/Makefile.sphinx, > while we don't have a Sphinx extension or fixup that would handle them > directly. So this all seems good to me and makes sense to get in for 4.10. Should I apply these? > NOTE: some images use more than 998 columns, causing troubles > with some MTA and MUA that could refuse them, because of an IETF > RFC 2821 violation: Hard would it be to bash out a little tool that could break those long lines? It seems like the format should be able to support that? I'm no XML expert, but a quick experiment breaking the long lines in fieldseq_bt.svg didn't create any problems; white space is white space. Indeed, given the small number of images and the infrequency with which they change, perhaps that could just be done by hand? (In the process I learned that if you visit an SVG image in emacs, it actually renders and displays the image!) jon