Re: First SVG graphic

[Tom Lane]

Bruce Momjian  writes:
> On Sat, Mar  9, 2019 at 02:17:33PM +0300, Jürgen Purtz wrote:
>> What is your opinion? Should we renounce the additional manual step and use
>> only the pure "Optimized SVG" format? This will increase the
>> 'diff-ablility', which may be valuable in the long term. But direct
>> readability of the files suffers more or less.

> Uh, so really there is plain SVG, "Optimized SVG", and readable SVG.  I
> am thinking you should store just "Optimized SVG", and provide a shell
> script to convert to readable SVG for those that want it.

Man, this discussion is leaving me disheartened.  It sure sounds like
we are going to end up in a situation where either everyone touching
the graphics has to use the same version of the same tool (with the
same options, even), or else we're going to have massive, unreadable,
and mostly content-free diffs in every patch.

regards, tom lane

Re: First SVG graphic

[Jürgen Purtz]

On 08.03.19 18:55, Peter Eisentraut wrote:

How do you get from the Inkscape SVG files to the what you call
"optimized SVG" files?

I loaded the gin_inkscape.svg file into Inkscape, saved it back out as
"Plain SVG", but the resultant file did not look at all similar to the
existing gin.svg.

Inkscape supports a lot of different formats. "Plain SVG" and "Optimized 
SVG" are two of them - and they differ in some aspects. "Plain SVG" is 
in some respect garrulous and generates unnecessary elements: 
namespaces, metadata, IDs, XML-entities. "Optimized SVG" avoids them, as 
long as you follow the hints described in 
https://wiki.postgresql.org/wiki/SVG_using_Inkscape. Conclusion: People 
working with Inkscape shall avoid "Plain SVG" and use "Optimized SVG".


Nevertheless Peter points out an important aspect. If you generate 
"Optimized SVG" out of the uploaded files, they look different in 
comparison to their original version. As mentioned in 
https://wiki.postgresql.org/wiki/SVG_using_Inkscape#Manual_corrections, 
it is possible - and sometimes advised - to manually 'optimize' the 
generated "Optimized SVG" file. I used this technique and tried to make 
the files good readable for everyone, especially because we are in an 
early phase of SVG integration. But apparently I have overstressed this 
possibility. You will find the following differences between the 
uploaded 'additionally manually optimized' files and the generated 
"Optimized SVG" files:


   - newlines

  -  element. This is an Inkscape optimization, which 
generates a group out of those elements, which are in a sequence and use 
- by chance - the same stroke-attribute. This optimization step is 
purely formal and in my opinion misuses the meaning of the  element 
as a cramp for logically related elements, e.g. to resize or transform 
them simultaneously.


As an example of such differences I append two files: gin.svg 
("Optimized SVG" plus my manually optimizations; the originally uploaded 
file) and gin_pure_opt.svg (pure "Optimized SVG").


What is your opinion? Should we renounce the additional manual step and 
use only the pure "Optimized SVG" format? This will increase the 
'diff-ablility', which may be valuable in the long term. But direct 
readability of the files suffers more or less.


Kind regards, Jürgen