Autocad Convert Pdf To Linework

[Amie Mandy]

HiIve drawn a linework illustration in AI ( im a novice in AI). The drawings is the silhouette of a woman. I want to import it into Autocad with the lines as simple lines. But when I export, the lines come into Autocad as filled shapes (with hatches), when all I want is a single width line. Surely there is a simple fix?

You haven't really offered enough detail about your workflow for anyone to troubleshoot it. It looks like you may have filled shapes there prior to export, perhaps having used a used a brush to draw the artwork...(?) What format did you export? Without knowing exactly what's on the artboard, it will be impossible to direct you. Can you post a screenshot with all selected and the Layers panel in view?

So I traced an outline of the woman using Adobe Fresco, using a vector brush. Then export to AI. From there I'm trying to convert to a DWG file. I take it I shouldnt use brushes? What should I use to trace the photo of the woman?

Well, I've never used Fresco, so I did a quick search for UI screenshots, and I see nothing but brushes. What I was looking for was a Pen, Pencil, or Line tool that would draw single-path vectors. There may be one in there somewhere, but you'd have to seek it out, apparently.

Seeing as this is the Illustrator forum, I assumed your art originated in Illustrator. I get why you posted here, given the AI format involved, but it seems the Fresco brush you used produced filled, closed paths (that's why it looks like double lines). I export simple paths to CAD formats successfully all the time from Illustrator. Do you run a copy of Illustrator?

Yes I have Illustrator. Im sorry. I though perhaps one could convert a brush to a pencil/pen or line in AI, perhaps not. I will toddle along to Fresco. I find Illustrator too difficult to freehand draw in.

If you select a line in your imported file from Fresco in AI, what do you see in the appearance panel? If there's a brush listed, change it to 'Basic'. If that doesn't help, please post a screenshot with the path selected and the appearance panel visible.

That would be the manual method of fixing it and akin to your desire to import blocks as just plain geometry. I have to do this each time I import most of the work from outside architects and civil engineers. Alternatively, you could ask them to set their pline thickness to 0 or those objects if they are keen to making your life a little easier ? There is really no good reason in AutoCAD to use the pline trick since the adoption of line weights like 20 years ago.

edit: Having autocad blocks imported as symbols might be a good thing for you if those symbols are repeated many times through the project. All you have to do is go into a symbol, fix the graphics, and all the instances will update accordingly. That might help with your doors and windows if you want to keep them as symbols instead of raw geometry. If each symbol is unique and not repeated in the file, I would opt for my method described earlier.

This happens to me on half of the DWGs I import. A couple years ago I got annoyed enough to make a little hacky script to stomp out crazy line weights. It's not an example of good scripting but I use it almost every time I import a DWG ? . It works on lines inside of symbols.

Once it's in your Resource Manager you can right click on the folder and choose open or go to Window > Script Palettes to open the palette. Once it's open double clicking the script in the palette will make it run.

OK so I ran the script and after a bit the screen redraws and nothing seems to have changed. When I double click and edit the 2D of the symbol, I see that the linework is indeed changed and without doing anything more, I exit the symbol and the linewt changes. So I will still have to enter each symbol individually.

I run the script. Less than 10 seconds passes and all of the objects blink off then on again with no visual change. When I enter the symbol I see that it actually has changed so I exit. Voila. But I still have to enter/exit the symbol.

Ha. I just read this script. Really clunky. If I get a second and @PatStanford doesn't beat me to it I'll make the ForEachObject criteria be not so bad and add a reset for symbols. It's another example of a script where the first time it did what I needed was the last time I looked at it. I've been using it for years not realizing how clunky it is ?

It's not all that clunky, really. I moved the LW variable in to the StompIt procedure since you don't need it to be global, and I added some indentation to make it a hair more legible. But the core script is about as elegant as it can be for what it does. The only change that I would consider making would be to add in a criteria for the ForEachObject procedure to only operate on the active layer (since DWG exports tend to be on a single layer immediately following import) to remove the possibility of accidentally overwriting intentionally set high line weights (I usually have a higher line weight on my title blocks, for example), or to just set all of the flagged objects to setting the line weight to be By Class, as I think that would be more useful in the long run. This comes with the added benefit of not needing an additional callback procedure for the ForEachObject procedure. These changes are made below:

Thanks @Jesse Cogswell ! I was going to take LW out of the criteria, since it makes absolutely no sense being there. And then do another procedure to find all the reset all the symbols. Might do it tonight depending on how the evening goes ?

@michaelk Oops, forgot to remove that criteria in the second script, since it's really not necessary. The ReDrawAll should cover doing the reset, at least it did in my (admittedly very quick) testing.

I just tried removing the LW test. In my original script -- that I've been using for years -- it let me declare a variable called LW and use the LW meaning Line Weight as part of a conditional in the criteria. Bone headed on my part. Can't believe that it worked at all ?

But using line weight in the criteria does an interesting thing. It only returns objects that can have a line weight. If you just look at objects on the layer or objects that aren't loci then it passes inappropriate objects, like symbols, to the procedure. Better to be lucky than good.

Looks like SetLW always uses Mils, no matter what the document line weight unit is. This version will only look at the active layer. In my quick testing it handles objects in symbols and in nested symbols!

Are the circle centre points the same as the polygon corner vertices? If this is correct then the approach in my previous reply will give you the polygons. as required. All you need to do the is for the Unfiltered features from the GeometryFilter, use an AttributeExposer to expose autocad_text_string and then use a PointOnAreaOverlayer to transfer the attribute onto the polygons.

Using your methodology, looking at the Help for the LineExtender, the Stretched port extends the line at both ends by the Extension Length, i.e., 1.5m each end. To assist with Area building after extending the lines, it would be worth pushing them through an Intersector. Then, at least, lines are broken where they intersect ready for area building (This also removes the need to drop lines segments inside the circles).

If the lines don't intersect where expected (irregular or not closed geometries produced) and the circle centre points are not the polygon corners, we are going to need to understand how a polygon corner vertex is meant to be defined in the CAD file.

To solve this, without getting the CAD redrawn, the arcs and lines that touch these Parcel circles and which end of the feature is touching, start, end or both, need to be identified (SpatialRelator, or an Overlayer).

For straight lines the LineExtender can be used to extend the line at the appropriate end (Need to test the LineExtender output to ignore the incorrectly extended lines, i.e., ignore the feature exiting Beginning if it should be End, and accept it passing through End.)

With Arcs there is a lot more work to be done to redefine the arc, with its new start/end point(s), but keeping the same primary and secondary axes, and centre point. I'd be looking at the ArcPropertyExtractor, ExpressionEvaluators to recalculate sweep angles, start angles, and 2DArcReplacer to recreate the complete, original arc geometry, but this list is not exhaustive for this workflow!

- I first run the workbench and find out parcels that fails to convert to polygons. These parcels can be identified by displaying parcel numbers that are left outside polygons. Then I go to AutoCAD and fix these parcels

With a pure FME approach I've got this far with your parcels:We're not going to get 21, 41, 42, 36, 49, and 45 by the current method, but FME will still be able to take us closer. Parcels 106, 34 and 38 all have at least one short line whose short end should be defined by a circle that is missing. If these last vertices were circled, this process would create and number these three parcels too.

A further issue we have in the CAD is the lines and arcs defining, what I assume is, the road on the West side of the site. Around parcels 37, 33, 54, 27, there are two boundary definitions with varying start and end points and different arc parameters. One would be the parcel and the other the road. Either they should be defined identically or road lines should be held on a different CAD layer to parcel lines. As a result we're creating a few small polygons that we shouldn't. Further cleaning before polygon building will help here.

It appears that when you import a C3D drawing TBC does not properly interpret these as 3D polylines. it appears to convert them to elevation zero. however, if yu explode them in C3D and import them, they are true 3D polylines. Has anyone else experienced this?

I don't believe TBC will import any C3D proprietary entities, e.g., feature lines, cogo points, corridors, gradings, surfaces, alignments, etc. Most of these things can be transferred via XML to TBC.

I would be careful importing C3D files with any special entities drawn. TBC will import the file but can do weird things with the resulting C3D entities; sometimes it will create text literally millions of coordinates away, among other things. I spend a great deal of time filtering all the C3D entities out of the DWG before I import to TBC. You can use QSELECT in Civil 3d to ensure you have all the civil entities exploded or removed prior to importing to TBC. Be careful of your order of exploding, too, as the civil entities are usually dynamically linked so any modifications to, let's say a surface, can change other things like gradings or corridors.

3a8082e126