Jump to content

Recommended Posts

Hello there,

 

I am drawing on a Wacom Bamboo Slate, which can export your drawings (and writing via a kind of OCR) to text, image formats and SVG. Here's Wacom's specs for the Slate: http://www.wacom.com/en/products/smartpads/bamboo-slate#Specifications

 

The Slate's ballpoint pen is marketed as having 1024 levels of pressure which in theory seems a bit much for a ballpoint pen, but would be nice if it could reproduce the light and heavy strokes you have made on paper. 

 

My problem is that the SVG files exported from Wacom's Inkspace app are filled black shapes instead of strokes. The shapes are thicker than the original paper lines, losing most of the line width variance, and I cannot find a way to reduce the width as you would with a stroke. I am attaching an image to illustrate my problem. 

 

Any thoughts on how to convert these shapes into strokes so that I could make them thinner? 

 

 

Many thanks in advance! 

 

 

 

 

filled_shape_vs_stroke.thumb.jpg.4ee710a469f9cafae2a503dadf0a3c6e.jpg

 

 

PS  there may be an answer in the thread below ('line width is not yet fully supported in the SVG standard'), but I'd like to confirm if something can be done about this using Affinity Designer?

 

https://forum.affinity.serif.com/index.php?/topic/45452-how-do-i-import-paths-they-keep-turning-into-shapes/#comment-227169

 

 

Share this post


Link to post
Share on other sites

Hi and thanks!

 

Please find attached the exported SVG file of a line/pressure test and a photo of the paper drawing for comparison. In case it's useful to you guys, I'm also attaching the original WILL file of the test.

 

I'm not very familiar with it, but WILL is Wacom's native 'vector ink' format in which the Bamboo Slate (and Intuos Pro Paper Edition, I think) records your work. They have even provided an SDK for others to use: 

 

https://developer-docs.wacom.com/display/DevDoc/WILL+SDK+for+ink+-+File+Format (see 'WILL Architectural Overview' for details on the WILL file format and its use of SVG)

http://www.wacom.com/en-us/enterprise/will

http://developer.wacom.com/en-us/will-sdk-digital-ink

 

 

Best, 

Dmitry

 

WCM0013.svg

IMG_6435.jpg

WCM0012.will

Share this post


Link to post
Share on other sites

Hello again, 

 

I received a reply from Wacom, but as it doesn't really take us any further, I have asked for clarification and given more details.

 

 

"Thank you for contacting Wacom Customer Support.

 

I am truly sorry for the late answer. 

 

Pressure changes are really only visible in SVG and higher zoom factors. 

Vector images: pressure is the thickness of the line so you can only see it in case that he will export as SVG.

But is this is only  visible under high zoom then in Raster will become blurry is this the conclusion? 

* Raster image - you  still should see the pressure sensitivity in this case when exporting in JPEG."

 

 

Any new thoughts from Serif's side as to how we could approach and alleviate this issue - is it a SVG standard issue, Affinity Designer issue or Wacom Bamboo Slate issue? 

Share this post


Link to post
Share on other sites

When looking into your supplied WCM0013.svg file,      it appears that everything of SVG there is always written as cubic Bezier curves into SVG path elements:

Quote

...
<path stroke="#000000" d="M 426.9 290.8 C 426.9 290.8 436.8 291.0 441.7 291.1 C 442.9 291.1 445.6 291.2 444.7 293.2 C 444.2 294.1 442.6 294.2 441.7 294.3 C 432.2 295.6 424.2 295.4 416.0 299.7 C 409.6 303.1 406.2 308.4 400.4 311.8 C 399.3 312.4 397.4 312.5 396.8 311.2 C 395.6 308.5 400.2 304.8 402.1 303.3 C 412.3 295.2 430.2 284.5 444.1 291.4 " />
...
<path stroke="#000000" d="M 579.8 255.9 C 579.8 255.9 580.8 258.3 580.8 259.5 C 581.1 270.0 581.3 280.4 581.6 290.8 C 581.9 303.7 582.8 316.6 582.8 329.5 C 582.8 329.8 583.2 331.0 583.0 331.6 C 582.8 331.9 582.8 333.3 582.5 333.9 C 581.7 335.8 578.4 333.9 577.8 333.3 C 575.9 331.5 577.0 324.2 576.9 320.6 C 576.1 302.4 575.8 287.3 575.5 268.4 C 575.4 266.4 576.0 250.4 580.6 257.2 " />
...

Note: that all drawing with the <path> element is specified inside the d="..." attribute. The d attribute contains the drawing commands, where M signals a "move to" command and the C signals an "curveto" (Cubic Bezier curve) command etc. - So that seems here to be the way Wacom's Inkspace app exports or generates then it's SVG code, it tracks the pen coordinates and everything is written as cubic Bezier curves.

When you import such an SVG file into AD it will show all curves as 1pt thick ones and you would have to alter all those settings accordingly (or for certain selected ones here) in order to change their thickness. Thus I don't see much which can be done here other than that.


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Hi v_kyr,

 

Thanks for your detailed reply! I'm not a programmer, but I could sort of follow your SVG code example and rationale, which I think is in keeping with what Wacom's Inkspace app seems to be doing when exporting an SVG file (specific coordinates creating filled shapes with a black #000000 colour). 

 

When I create a single stroke with a vector brush in Affinity Designer and export to SVG, the resulting file looks scrambled and very different in a plain text editor (comparison screengrab attached). 

 

With your knowledge of SVG code, would you reckon that Wacom could feasibly export an SVG file from their native WILL file, with strokes you can re-size instead of these filled shapes? Or, are Wacom's developers dependent on the SVG standard (not) supporting strokes/strokes with variable width and, really, we're stuck with this?

 

None of this is the end of the world, but it's a shame that the otherwise nice hardware features of the Wacom Bamboo Slate product (and other products e.g. Neo Smartpen N2) are hampered by Wacom software issues or SVG file standard issues. For something like pen pressure or crosshatching (in the above photo), the SVG can look like a dark mush instead of natural hatching, which is a pity! 

Wacom export SVG vs AD export SVG.png

Share this post


Link to post
Share on other sites
2 hours ago, Dmitry said:

When I create a single stroke with a vector brush in Affinity Designer and export to SVG, the resulting file looks scrambled and very different in a plain text editor (comparison screengrab attached).

Are you shure you used a vector brush here and not an image, since that svg_test_stroke.svg screenshot shows and looks more like sort of an embedded PNG image instead? - Usually drawn shapes, lines etc. (aka curves) are written in common readable SVG element commands when exported from Affinity Designer.

Quote

With your knowledge of SVG code, would you reckon that Wacom could feasibly export an SVG file from their native WILL file, with strokes you can re-size instead of these filled shapes? Or, are Wacom's developers dependent on the SVG standard (not) supporting strokes/strokes with variable width and, really, we're stuck with this?

That's hard to tell, meaning here what they are capable to capture internally with those Wacom Bamboo Slate devices and if they could export or generate different SVG code. Even SVG supports different elements (rect, circle, line, polyline, ellipse, path, text, image, strokes and fills...etc.), see for example here, but how should that Slate device know what you have drawn in freehand style on paper here?

Meaning the device doesn't know if you have drawn a line, a rect or circle etc. All it knows instead is, that you pressed down the pen at some coordinates on the calibrated paper size with some pressure, that you have moved with pen down to other paper positions and that you lifted from the paper on some other coordinate. So it may can only track those things here, finally a bunch of x/y+p data etc. And that's what they write out as generated SVG code here.

I don't know what their WILL format is at all, would have to take a look into it first, so what I said here is just based on the contents of your SVG example file!

 


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Hi there,

 

Thanks for the SVG tutorial!

 

Vector brush - yes, I'm pretty sure it was a vector brush... erm, I was in the vector paint side of AD and using one of DAUB's/Paolo Limoncelli's brushes (please see screengrab and the AD-exported SVG), so yes, that should be OK.

 

I don't know about Wacom and their WILL format either. I have been trying to get information from Wacom and whether they could export the SVG as a stroke that I could make thinner or that they could have a pressure curve preference in their Inkspace app for people with a lighter touch (the line thickness/tapered ends issue), but I'm still waiting for information. I'd be happy with just thinner lines, but I guess that defeats the purpose of Wacom advertising pressure sensitivity etc.

svg_test_stroke.svg

svg_test_stroke.png

Share this post


Link to post
Share on other sites

BTW the SVG stroke-wide property defines usually the thickness of elements (aka more precisely here specifies the width of the outline on the current object). Its default value is 1. If a <percentage> is used, the value represents a percentage of the current viewport. If a value of 0 is used the outline will never be drawn etc. - In your initial "WCM0013.svg" there is no explicite defined stroke-width and thus all drawings there are as default 1 for the by the Wacom Bamboo Slate generated/exported SVG code. Without zooming deeply into the drawing there you won't determine any obvious line thickness differences.


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Sounds familiar...

 

Here's a screengrab of the WCM0013.svg file in AD, when selected and with the black fill removed. Note the stroke palette (1pt) - I guess this is what you mean, right? Makes sense in this case that the stroke value would only affect the outline of the Inkspace exported images. And why I can't reduce the size of the whole shape 'like a stroke'.

 

By the way, I just noticed that when I try to re-import the image I attached in my previous post (real stroke drawn in AD, svg_test_stroke.svg), it opens as an (Image) layer and I can't edit the stroke's nodes at all, like I can the outline nodes of the SVG exported from Inkspace. Shouldn't I be able to re-import that AD exported SVG and edit the nodes?

 

 

Although, I return to what I was wondering about earlier: does no method / tool exist to convert a filled outline shape (as exported by Inkspace) to an stroke? Or in any vector application - is this just not possible?

 

Again, I'm not a programmer, but one would think that if the Inkspace app/Slate is recording each line/stroke's coordinates *in the right order* to the WILL/SVG file (as in the SVG code sample you quoted), then the first 'coordinates' for each stroke could be interpreted as the beginning point of a stroke and the last coordinates as the end point of a stroke?

WCM0013.svg_screengrab.png

Share this post


Link to post
Share on other sites
2 hours ago, Dmitry said:

Here's a screengrab of the WCM0013.svg file in AD, when selected and with the black fill removed. Note the stroke palette (1pt) - I guess this is what you mean, right? ...

Yes that was what i meant.
 

Quote

 

By the way, I just noticed that when I try to re-import the image I attached in my previous post (real stroke drawn in AD, svg_test_stroke.svg), it opens as an (Image) layer and I can't edit the stroke's nodes at all, like I can the outline nodes of the SVG exported from Inkspace. Shouldn't I be able to re-import that AD exported SVG and edit the nodes?

 

IMO that's an embedded PNG image, so what is shown there in your file is bitmap binary data and no vector data at all, thus you can't edit it that way.

Quote

Although, I return to what I was wondering about earlier: does no method / tool exist to convert a filled outline shape (as exported by Inkspace) to an stroke? Or in any vector application - is this just not possible?

I didn't looked or searched the internet after such tools, thus I can't tell. But maybe someone in the Wacom forums who also uses that Inkspace tool can give you some tips or hints here? Further usually Wacom should be able to tell you here, since it's their software and API etc.

When manual coding you can do so with SVG path elements, like shown here in this test...

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="400px" height="210px">
  <g fill="none" stroke="black">
    <path stroke-width="2" d="M5 20 l215 0" />
    <path stroke-width="4" d="M5 40 l215 0" />
    <path stroke-width="6" d="M5 60 l215 0" />
  </g>
</svg>

path-no-fill.jpg.696a474aa5c123f28c05612a97c1a9b9.jpg

 

Quote

Again, I'm not a programmer, but one would think that if the Inkspace app/Slate is recording each line/stroke's coordinates *in the right order* to the WILL/SVG file (as in the SVG code sample you quoted), then the first 'coordinates' for each stroke could be interpreted as the beginning point of a stroke and the last coordinates as the end point of a stroke?

Well you can "unzip" that WILL file and look into it's directory/file structure contents, maybe there is some file with readable informations about the way it recorded a session etc. But as far as I have seen, they seem to capture things there instead in a binary paths.protobuf file and other setup stuff in XML files.

<?xml version="1.0" standalone="yes"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
	<Default ContentType="image/jpeg" Extension="jpg"/>
	<Default ContentType="image/png" Extension="png"/>
	<Default ContentType="application/vnd.willfileformat.path+protobuf" Extension="protobuf"/>
	<Default ContentType="application/vnd.openxmlformats-package.relationships+xml" Extension="rels"/>
	<Default ContentType="image/svg+xml" Extension="svg"/>
	<Override ContentType="application/vnd.willfileformat.extended-properties+xml" PartName="/props/app.xml"/>
	<Override ContentType="application/vnd.openxmlformats-package.core-properties+xml" PartName="/props/core.xml"/>
	<Override ContentType="application/vnd.willfileformat.paint+protobuf" PartName="/style/paints.protobuf"/>
</Types>

 

 


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Hi there, 

 

That's odd about the embedded PNG image. However, looking at the SVG export window in AD, I can see that I made a mistake here. I had a 'rasterise unsupported properties' and some other boxes ticked, which would explain the lack of vector data. With some changes and opening the SVG file in a plain text editor, the format of the code became similar to your earlier SVG examples.

 

Using your new SVG code sample, I also tried to experiment with my earlier SVG files' code. I removed the fill, added the black fill and used <path stroke-width="2" and "1" etc. But, of course, this didn't change the thickness of the original shape outline, so unfortunately it's not an improvement. As far as the WILL file is concerned, perhaps if other companies get to look into Wacom's SDK, compatibility might improve...?

 

Anyway, thanks for all the help! 

 

I tried Wacom's email support and three forums on Facebook earlier, with no real help. So, being an AD user, I thought I'd try here, in case I could learn more about Serif's support for SVG (or WILL) or possible mistakes of my own. It looks like I will have to deal with the issue and definitely not shade things too closely in drawings. Or, stick with pencil. Seems like the hardware part of the Bamboo Slate product is being slightly wasted as far as pressure and vector export is concerned. But - I'll get back to Wacom in the hope of an answer! 

 

Thanks again -

Dmitry

Share this post


Link to post
Share on other sites

Well these Inkspace app/Slate exported SVGs seem to trace the pen thickness, similar like a vector tracing app here. Thus it probably gives closed shape paths/curves here as coordinates. I don't know if that Inkspace app allows to finetune settings and to edit or optimize the drawings it recognizes (?). See nothing here shown is just a plain SVG line path, even thin lines are shape paths/curves:

wc_no_fill.thumb.jpg.c631b221ffd79daf19bb686edb30aaf2.jpg

You might want to look if there are some Inkspace customization possible, sort of preferences settings or the like. - Other than that there are some SVG optimization tools available like SVGOMG , SVG Cleaner and SVG-Optimizer etc., you have to check if any of these maybe can offer anything useful here.

For lines SVG also has this here ...

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" width="250px" height="200px">
  <g fill="none" stroke="black">
    <line x1="0" y1="50" x2="200" y2="50" style="stroke:rgb(255,0,0);stroke-width:2" />
    <line x1="0" y1="60" x2="200" y2="60" style="stroke:rgb(0,0,0);stroke-width:2" />
  </g>
</svg>

... but you would then need some sort of converter app which would rewrite the Inkspace exported SVGs then in some correct working manner.


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Yes, exactly - perhaps Wacom records data in this way (outlines) to save details in the lines. I'm thinking about the 'beauty' of exported raster files etc. But choosing closed vector shapes over plain strokes also means that I can't make these lines any thinner, like I can with strokes created in AD (with a 'spine' of nodes in the middle). 

 

The digital lines (both in Wacom's app - the native WILL file - and the exported SVG) are: 

- thicker than on real paper meaning that when I do 'crosshatching', or a lot of lines close to each other, they visibly just turn into one black area (as if I was colouring in the area).This just looks like a 3rd gen photocopy. 

- and the lines are pretty uniform in line pressure, compared to the lines on paper. 

 

So, my problem is that the digital versions of the drawings are very clumsy and don't look like ballpoint pen (the Wacom Slate's pen). 

 

For this reason, I originally asked Wacom about this issue and suggested that there could be a pressure curve preference in their Inkspace app, so that people with either heavy or light hands could set the sensitivity of the pen and get more elegant lines. I mean, they already have code for this kind of thing in their drivers etc. Painting apps also have similar pressure curve features, on mobile and desktop. 1024 levels of pressure sounds a lot for a ballpoint pen - honestly I'd be happy with X levels of pressure that *really looked like* thin/light lines and normal thickness/dark lines! 

 

Thanks for the links to the optimisation tools and code! I'll deliver this information to Wacom and hopefully they'll have means to approach this, as I'm not sure what else to do other that just get on with it. Will let you know what they say, unless they write here first. 

Share this post


Link to post
Share on other sites
Quote

...The digital lines (both in Wacom's app - the native WILL file - and the exported SVG) are: 

- thicker than on real paper meaning that when I do 'crosshatching', or a lot of lines close to each other, they visibly just turn into one black area (as if I was colouring in the area).This just looks like a 3rd gen photocopy. 

- and the lines are pretty uniform in line pressure, compared to the lines on paper.

So, my problem is that the digital versions of the drawings are very clumsy and don't look like ballpoint pen (the Wacom Slate's pen). ...

Well I looked at this video here to get an idea about this Wacom device and that Inkspace software. There at least the Inkspace app itself on screen shows a clear difference between thick and thin pressure lines, though that guy there used a ball pen instead for his tryouts. In that video when he exports to PDF vectors it looks for a second or so the same as what you see when exporting to SVG, namely Bezier curves paths.

I also looked into that WILL SDK FAQ and saw there the following related ...

Quote
Can the ink convert ink to a SVG or PDF?

Yes. Using the class WCMBezierPathUitls on iOS; Module.BezierPath on Web; BoundaryBuilder on Android; the ink can be converted to a Bezier curves path, describing the boundaries of the ink. With this path, the developer can produce SVG or PDF, using a suitable API for his platform.

... which states: "...the ink can be converted to a Bezier curves path, describing the boundaries of the ink". - So it looks like their API actually seems to support only to export Bezier curve paths which then in turn do resemble the ink boundaries here (see also)!


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Oh, I must have been a bit unclear at the beginning!

 

The Wacom Bamboo Slate product is indeed a pressure-sensitive ballpoint pen and standalone tablet combination, hence my photos comparing paper and SVG files etc. Sorry for the confusion! The pen uses Wacom's electromagnetic technology to work. You then sync the Bamboo Slate to your phone/tablet and export your work via the Wacom Inkspace app. It also supports optical character recognition, which works pretty well (at least in English). 

 

Teoh Yi Chie's Bamboo Slate review compares the 'on paper' pressure vs 'on screen' pressure differences well at about 12:26. And the on screen output doesn't look too bad!  But: have a look at when I try normal pressure vs very light pressure on paper (image attachment). In the digital on screen version, the difference between normal and very light pressure creates lines that are really quite similar. 

 

So, there's the SVG 'shapes vs strokes' problem (can't really adjust size in Affinity Designer) and there's this line thickness problem of the hardware working but software letting it down, causing very dark and thick output. This is where I think it might be a question of software interpreting pressure data in a certain way, and that this could be improved upon to create more subtle digital linew ork. 

 

In fact, an other reviewer, Brad Colbow, commented (see at about 3:00 of his review) that "I was really impressed by how much (the Slate) captures"  ...  "but (I) couldn't shake my initial impression that I just didn't enjoy using this thing…" For him, the reason was the software. Not much work seems to be put into the Inkspace app. 

 

https://www.youtube.com/watch?v=sMmnN1QnpXU

 

By the way, I just got an email from Wacom email support (below), but unfortunately I am none the wiser, so I sent a new reply + citing this forum discussion. Note that the message says "you could adjust stroke width in Illustrator". I don't have Illustrator, but as we are still talking about the same SVG files, I wonder if there's a difference?

 

Wacom's email:

 

"There is a difference between the ink left on paper by the physical pentip and the pressure seen by the digitizer in the smartpad. The smartpad can only measure the applied pressure, but the width on paper depends on the ink cartridge and paper material. The Slate tries to record as much detail as possible, but does not necessarily reproduce the look on paper hundred percent. The main purpose of the device is to record notes and sketches for further processing - conversion of handwriting to text or working with the SVG vector data in programs like Illustrator. - Currently there is no option to adjust pressure sensitivity and pressure curve, but you could adjust stroke width in Illustrator.

I could not check the forum as the link is restricted. "

 

 

on_screen_vs_on_paper_pressure_differences.png

Share this post


Link to post
Share on other sites
Quote

So, there's the SVG 'shapes vs strokes' problem (can't really adjust size in Affinity Designer) and there's this line thickness problem of the hardware working but software letting it down, causing very dark and thick output. This is where I think it might be a question of software interpreting pressure data in a certain way, and that this could be improved upon to create more subtle digital line work...

Well I don't know or can't tell if Illustrator offers additional other things here beside adjusting the contour of curves etc. when dealing with imported PDF/SVG data. - However you can also adjust the outline thickness in AD too slightly here, but you can make these SVG shapes generated by that Inkspace app mostly only obviously thicker and not much lighter/thinner.

thicker.jpg.7f5c99ca64462f307bb626700a4fbff1.jpg

In order to yield the result you are probably looking after, you would have to adjust all the shapes nodes here accordingly (shape to stroke), meaning to edit the outline nodes to get more like a single stroke line style. Here I manually overlapped the shape nodes to strokes, afterwards then you can of course adjust the thickness with AD in a much finer way.

manual-nodes-adjust.jpg.78d43adab7885fb12dcf56b611daf6ca.jpg

But that's usually nothing you want to do always manually for thousands of possible objects/nodes in drawings by hand. Instead you would expect to have some software generated support for this!

 


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Yes, exactly! It would be quite frustrating to manually work on each shape/stroke over the course of multiple sketches.

 

What I was hoping for in AD would have been something like a 'Select All + reduce all strokes by x percent' kind of a thing, since I have not had any concrete feedback from Wacom re: choosing shapes/outlines vs strokes and pressure sensitivity preferences. I think Adobe Illustrator has some tool/brush to 'squeeze/pinch' the strokes (or outlines) to make them thinner (maybe the 'pucker' tool?)

 

Still, other pen products with pressure sensitivity have similar issues - the pen detects many levels of pressure, but the software only shows very similar + limited level of strokes (as at 5:50 in this video: https://www.youtube.com/watch?v=8Ewv3T4En9A&app=desktop)

 

 

Anyway, here's hoping that things will improve! 

Share this post


Link to post
Share on other sites

Yes the main point here for you is probably this one:

Quote

1. Create Simple Shapes Using Simple Shape Elements, Not <path>s.

There is a reason we have different basic shapes in SVG for creating, well, basic shapes. One could create practically any shape using a <path> element, right?

Simple shape elements (<line>, <circle>, <rect>, <ellipse>, <polygon> and <polyline>) are there for many reasons, and one of these reasons is that they are more readable and more maintainable and editable by hand than their <path> alternatives.

Basic shapes come with a set of attributes that allow you to control the shape features, such as position (x, y, cx, cy) and dimensions (width & height), while paths don’t come with these attributes.

For example, the following snippet shows the difference between a circle created and exported as a simple shape, versus one created and exported as a path:

?
<circle fill="#FFFFFF"
        stroke="#000"
        cx="28.1"
        cy="28.1"
        r="27.6"/>
 
<!-- versus -->
 
<path fill="#FFFFFF"
      stroke="#000"
      d="M55.7,28.1
         c0,15.2-12.4,27.6-27.6,27.6
         S0.5,43.3,0.5,28.1
         S12.9,0.5,28.1,0.5
         S55.7,12.9,55.7,28.1z"/>
...

 

See these:  Tips for Creating and Exporting Better SVGs for the Web

Though I'm not sure if usual simplify tools do take this somehow into account at all here. Meaning there are SVG related tools like svgo and/or svgop (a standalone binary executables for macOS and Windows of 'svgo', the SVG optimizer), but AFAIK those don't convert paths to simple shape elements.


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Actually, that's a good point in there - for animators, who could sketch something quick and export the vector artwork into a vector animation package. Moving, animating and modifying the vector artwork would be easier (I can imagine) with simpler strokes.

 

I tried to install some of the Github simplify tools in the Mac OS X Terminal but ran into some kind of installation/dependency problem, might have a look later... Or, could try a trial version of Illustrator to see what that article means regarding the simplify etc. tools. If Illustrator had an opposite tool to what is used in this video, and AD had something similar, that could do the trick (i.e. in the 'outline to stroke' direction): https://www.youtube.com/watch?v=F2oSR0Oh25c 

 

Share this post


Link to post
Share on other sites

BTW I recently used autotrace and then remembered that it offers to support center line tracing, which might be useful here for your problem. - I did a rough and quick test with your initial image as a JPG (since most tracer apps use only bitmaps as input) and throwed that on the RapidResizer tracer/converter which can output SVG too. The result is a smoothed single line SVG path (no outlines) of the whole, take a look here on the resulting SVG file:

So it can basically produces what you want, though in this case as a single line path curve. However there are already some projects which deal with center line tracing for Inkscape by using autotrace instead of potrace. See:

cmdshell> autotrace -centerline -color-count 2 -output-file output.svg -output-format SVG input.png

So autotrace might be an option here when you past over your Slate output as a bitmap. Note however that autotrace has a bunch of options for adjustments and fine tuning, thus you have to play around with these and see which might give you the best desired results. Also that above mentioned Inkscape centerline tracing support might be useful when using Inkscape for modifying your Slate SVGs.


☛ Affinity Designer 1.7.0 ◆ Affinity Photo 1.7.0 ◆ OSX El Capitan

Share this post


Link to post
Share on other sites

Thanks! 

 

Definitely interesting, although I'm afraid it's probably not useable for my purposes in its current state. Overall - this is promising in proving the tracing technique (in lack of Wacom attention to their export process + options for pressure preferences + centre line strokes), but the output details tend to simplify the lines quite a lot. (and at times, are a bit random, e.g. in the 'crosshatching' parts in Tracing.svg.

 

I tried the RapidResizer site and Inkcape's default tracing tool (installed via X11 on my quite old Mac OS X 10.7.5 set up), but got into trouble with installing the mac version of autotrace, for which the Mac Terminal gave me:

 

Error: No available formula with the name "autotrace" 

(even in previously deleted formulae)

 

and 

Error: No formulae found in taps.

 

I have homebrew installed along with python (in the hopes of learning python at some time, soonish), so that should be ok. Possible that I've messed something along the line, though.

 

But - absolutely - I could trace an image with RapidResizer, import it into AD and apply a stroke etc., so the centre line tracing technique itself works!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×