Trimming an SVG
-
Okay, my brother asked me for the capability to take a snapshot from OpenStreetMaps. Now, I could use the export function of Openstreetmaps.org which does exactly what he wants. Some AJAX-requests and so on and so forth.
However, that would make him dependent on the availability of the OSM server and the export function is not that fast. It also can fail sometimes, a fact they tell you about beforehand.
Now, I could implement the same service for my region on my server. However, to fully make use of that I'd need to crop the SVG - really crop it and not just adjust the viewbox or something.
So, anyone know of an implemented solution I could use? Because otherwise I'd need to check which paths are visible in the viewport, delete the invisible ones and trim the ones which are partially-visible.
-
@Rhywden You might just crop the objects that don't overlap with the viewport; though there are algorithms for doing the whole job, they're a little complicated. OK, they're mostly complicated so they handle the “concave crop region” case right, but I really wouldn't want to bet that you won't have the complexity.
But I bet most objects will either not overlap or be sufficiently visible to be not worth cropping.
-
Can you print the viewport to a pdf?
-
@Rhywden Is this a one-time thing or something that needs to be automated?
-
@blakeyrat Needs to be automated - the workflow is:
- User moves and zooms on a map until he has found the piece he wants
- This piece is then cropped to contain only the paths needed.
- The resulting SVG is then further manipulated by changing colours for some closed paths and/or adding icons
- The resulting SVG is then shipped off to a printer.
-
@dkf said in Trimming an SVG:
@Rhywden You might just crop the objects that don't overlap with the viewport; though there are algorithms for doing the whole job, they're a little complicated. OK, they're mostly complicated so they handle the “concave crop region” case right, but I really wouldn't want to bet that you won't have the complexity.
But I bet most objects will either not overlap or be sufficiently visible to be not worth cropping.
From what I've seen, the SVG I get from something like OSM does not contain Beziér curves or something like that - it's usually just a bunch of paths with coordinates.
-
@dse said in Trimming an SVG:
Can you print the viewport to a pdf?
Not that I've seen, no. And I need to manipulate the result further, so a PDF would only add uneeded complexity.
-
@Rhywden So if I understand correctly, you have your own version of OpenStreetMap hosted on your own server, with the full map data, correct? And what you need to do is to write a server-side program that will "crop" this full map data to a particular set of coordinates on demand and save the resulting image?
(I'm not sure you want random idiots on the Internets to be able to print stuff, though. Printing costs money.)
I don't know exactly how OSM stores data, but if it's all in one big-ass SVG the simple solution should work fine. (Erase all paths that don't/can't intersect your viewport, draw a rectangle around what remains, fill shit outside the rectangle with opaque white, then reset the image size.) SVG's a pretty easy format to work with, the hardest part of this is finding paths that can't intersect the viewport. But if there's no beziers, that's a bit easier too. Line segments are a breeze. Keep in mind you don't actually have to clip the line segment ends (although that isn't too difficult anyway-- every 3D engine pre-GPU had to do that). You can leave them there shooting outside your image in every direction. Just cover them up with opaque white, let the printer figure it out.
If the data's not hugemongous or you need the code now now now you could just not erase any SVG data, but only add the border and header changes you need, then print the whole-shebang and let the printer figure it out.
-
@blakeyrat Is there a sneaky reason to fill outside the viewport? SVG will only show you a viewport rectangle by default.
Actually, why don't you just do that? Change the SVG viewport or move all the path elements that use absolute coordinates to inside the viewport or whatever, then do your post-processing and print. Your SVG will be fatter than necessary but disk is cheap.
-
@AyGeePlus said in Trimming an SVG:
@blakeyrat Is there a sneaky reason to fill outside the viewport? SVG will only show you a viewport rectangle by default.
Last time I was fiddling with it, I recall that the viewport didn't clip elements extending outside of it. Then again, it might have just been that specific SVG I was working with at the time, I'm not an SVG expert.
If you don't need to fill outside with white, then don't. Simple solution to this conundrum.
@AyGeePlus said in Trimming an SVG:
Actually, why don't you just do that? Change the SVG viewport or move all the path elements that use absolute coordinates to inside the viewport or whatever, then do your post-processing and print. Your SVG will be fatter than necessary but disk is cheap.
That was my "if you really need to get this done RIGHT now" suggestion.
-
@blakeyrat Ah, that makes sense. Will ask my brother if that's okay - he's the one who has to deal with the printers.
And, no, this is part of a university project and the printer in question will not be directly connected to the server. Unless you know a cheap one which prints on sheet metal?
-
@Rhywden Well, my ideas kind of assume a print server/printer firmware that supports PostScript or PCL, basically one with a lot of smarts when it comes to taking vector input (including Z-order and occlusion) and converting it to high-DPI pixel output.
If his university metal printer doesn't have a driver like that, all bets are off. You might have to end up reducing the SVG file. But it's worth a try either way.
-
@AyGeePlus said in Trimming an SVG:
Actually, why don't you just do that? Change the SVG viewport or move all the path elements that use absolute coordinates to inside the viewport or whatever, then do your post-processing and print. Your SVG will be fatter than necessary but disk is cheap.
That was my "if you really need to get this done RIGHT now" suggestion.
I guess I was speaking to Rhwyden then? My past decisions are inscrutable. I've been messing around with some SVGs for work, and I know Chrome will only show you stuff inside the viewport and clip the rest, but I wouldn't be surprised if that kind of thing was incredibly SVG-driver specific. There's probably no way to know what the sheet metal printer prints without trying it.
