Re: Documentation and explanatory diagrams

Ross J. Reedstrom wrote:
> On Mon, Jun 13, 2011 at 09:17:04PM +0000, Thom Brown wrote:
> > >
> > > xmllint --format for_test_here.svg | wc -l
> >
> > That restores some of the newlines, but inkscape seems to place tag
> > attributes on their own separate lines for readability, so the outputs
> > still differ, unless you pass both through that same process.
> > Comparing two processed outputs still reveals a difference, such as a
> > comment in the original saying "Created with Inkscape..." and some
> > attributes not preserved by LibreOffice, including namespaces Inkscape
> > uses that LibreOffice doesn't.
> >
>
> Those sort of things, if they don't dominate the diff, are
> pretty easy to skim past, as long as larger scale changes (like altering
> the paths, as described above) don't interfere. I think anything beyond
> hand-crufted xfig is going to have some less-than-absolute minimal
> changes. And there are only two of us are left who know how to hand
> cruft xfig!

Agreed on the simplicity of manually modifying xfig files. :-)

I think we are agreed on using the SVG format to check images into git.
I think the unknown is which SVG editor XML file layouts we will
support.

I would like xfig's SVG export format to be supported as a way for me to
import my images into our docs, and it seems Greg Smith has similar
needs. I don't see that xfig can import SVG so I think it will be a
one-way operation.

I think the big question is whether we can afford to allow multiple SVG
editor file formats to be checked in, and hence support git diff churn
as we switch SVG editors for commits. This doesn't seem likely to
improve anytime soon so we should just decide and move forward.

Perhaps we should allow any SVG file to be imported, but only allow
modifications by a single SVG editor.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +