public inbox for [email protected]
help / color / mirror / Atom feedFrom: Jürgen Purtz <[email protected]>
To: [email protected]
Subject: Re: First SVG graphic
Date: Sat, 9 Mar 2019 14:17:33 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
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
- <g stroke="black"> 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 <g> 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
Attachments:
[image/svg+xml] gin.svg (6.4K, 2-gin.svg)
download | view image
[image/svg+xml] gin_pure_opt.svg (5.8K, 3-gin_pure_opt.svg)
download | view image
view thread (64+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: First SVG graphic
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox