This has to be a simple problem, but I can't find the answer. I'm attempting to import a document that was converted to SVG from PDF using the https://www.idrsolutions.com/online-pdf-to-svg-converter. The destination is a new empty document. Using either the File - Import... or copy-paste, the stroke style of the incoming rectangles gets changed.
Here's what the selection looks like in the origin document:
And this is what it looks like after pasting into the destination.
No, that wasn't tried, I'm not sure why. It does produce a better result, with stroke styles unchanged. It also produces objects that I can't figure out how to ungroup, but I can adapt the workflow around it. Thank you!
I'd still like to understand the original problem.
The original issue will depend on the methods used for conversion from PDF by the online tool. Styles (stroke/fill/opacity/etc.) can be applied at various points in the file, including via reference. So if an object is copied/pasted and a referred resource (not inline) is not also copied with context (paths, etc.), some things may not work as expected.
So if an object is copied/pasted and a referred resource (not inline) is not also copied with context (paths, etc.), some things may not work as expected.
Here's a repeatable process for me:
Create new blank document.
File - Import an SVG created by the IDR converter into Layer 1
Create Layer 2
File - Import a different SVG created by the IDR converter into Layer 2
Toggle the visibility of Layer 1
Rectangles in Layer 1 now have an outline.
Here's another:
Create a new blank document.
Delete Layer 1
File - Import an SVG created by the IDR converter into the document root.
File - Import a different SVG created by the IDR converter into the document root.
Create Layer 1.
Move either of the imported drawings into layer 1.
WRT post #5, the Inkscape svg can be reduced in size by ungrouping every last group and saving. Saving a copy as plain svg after ungrouping may also help.
Feel free to share 11742-A01-FL01.pdf and the idg svg here, or DM me for email addy if the info is proprietary.
The most useful svg document will have as few unneeded objects as possible, but not use classes for styles (as in the online conversion). This will provide the most editing flexibility.
When using the Inkscape pdf conversion to svg, this document has thousands of unneeded objects. (This is a result of the original conversion to pdf.) But styles will be inline.
Using the Inkscape conversion and copying the plan's wings and using "Paste in Place" to the new document, and copying/pasting-in place one half of the main building at a time to the new document will reconstruct the drawing with inline styles. This is good, but it takes time, as each area has ~1500 objects.
I would not copy any of the title block or scale/legend, they contain more objects than the rest of the drawing.
The resulting new svg will be ~1500kb, but its pdf copy will be small.
That works, of course, resulting in a 2.2mb file for the merged wings.
The SVG files will be used as the basis of an interactive map application in a browser window. There are 800+ buildings, 70 of which have multiple floors. IDR offers a bulk PDF -> SVG conversion service, but since each drawing will have to be touched manually to add interactive regions, using the Inkscape import wouldn't be a big issue. The issue is 1500ms load time for the larger Inkscape-converted files, vs. 300ms for the smaller IDR file.
On the other hand, it appears that if I don't try to put the two floors together in different layers of the same SVG, the box outline problem doesn't appear; with decent load times, switching between floors of the same building by loading a new file will work almost as well as toggling visibility of layers within the SVG.
So apparently the answer to the original question is that whatever optimization the IDR conversion process uses introduces complexity that Inkscape isn't able to handle in certain rare situations; I'll take the question up with IDR as a possible bug in their conversion. I appreciate your help in finding a work around.
It is not a bug, it is the implementation of the file. A style such as a stroke (border) can be placed inline with each object, or a shared style can be pointed-to. This style can be on a separate server if desired. This can present issues with editing, but will offer smaller file size.
Beginners' Questions Pasting into a new document changes stroke style
Inkscape.org
This has to be a simple problem, but I can't find the answer. I'm attempting to import a document that was converted to SVG from PDF using the https://www.idrsolutions.com/online-pdf-to-svg-converter. The destination is a new empty document. Using either the File - Import... or copy-paste, the stroke style of the incoming rectangles gets changed.
Here's what the selection looks like in the origin document:
And this is what it looks like after pasting into the destination.
What am I missing? Thanks.
Bob
Had to say without seeing the original pdf/svg.
JFYI, Inkscape can import most PDF files. Was that tried?
No, that wasn't tried, I'm not sure why. It does produce a better result, with stroke styles unchanged. It also produces objects that I can't figure out how to ungroup, but I can adapt the workflow around it. Thank you!
I'd still like to understand the original problem.
Bob
The original issue will depend on the methods used for conversion from PDF by the online tool. Styles (stroke/fill/opacity/etc.) can be applied at various points in the file, including via reference. So if an object is copied/pasted and a referred resource (not inline) is not also copied with context (paths, etc.), some things may not work as expected.
Ah, rediscovered why the Inkscape PDF import isn't usable: 7.5 x multiplication of file size:
Here's a repeatable process for me:
Rectangles in Layer 1 now have an outline.
Here's another:
All rectangles in both drawings now have borders.
Is this a bug?
WRT post #5, the Inkscape svg can be reduced in size by ungrouping every last group and saving. Saving a copy as plain svg after ungrouping may also help.
Feel free to share 11742-A01-FL01.pdf and the idg svg here, or DM me for email addy if the info is proprietary.
If you can tease out the issue, I'd be grateful.
Bob
If you can tease out the issue, I'd be grateful.
Bob
Here's my take...
I presume there will be more documents like this?
That works, of course, resulting in a 2.2mb file for the merged wings.
The SVG files will be used as the basis of an interactive map application in a browser window. There are 800+ buildings, 70 of which have multiple floors. IDR offers a bulk PDF -> SVG conversion service, but since each drawing will have to be touched manually to add interactive regions, using the Inkscape import wouldn't be a big issue. The issue is 1500ms load time for the larger Inkscape-converted files, vs. 300ms for the smaller IDR file.
On the other hand, it appears that if I don't try to put the two floors together in different layers of the same SVG, the box outline problem doesn't appear; with decent load times, switching between floors of the same building by loading a new file will work almost as well as toggling visibility of layers within the SVG.
So apparently the answer to the original question is that whatever optimization the IDR conversion process uses introduces complexity that Inkscape isn't able to handle in certain rare situations; I'll take the question up with IDR as a possible bug in their conversion. I appreciate your help in finding a work around.
Bob
It is not a bug, it is the implementation of the file. A style such as a stroke (border) can be placed inline with each object, or a shared style can be pointed-to. This style can be on a separate server if desired. This can present issues with editing, but will offer smaller file size.
More info on css can be found in the fine tutorial series by Mark: http://www.peppertop.com/blog/?p=1563