Art V

I third @zoomerand 2nd @Kevin McAllister, setting snaps on/off could be made simpler including a quick all on/off option.

Yes it should be possible to have hidden lines respond to a class setting controlling its appearance. It saves from creating workarounds with manually created classes for imitating hidden lines.

Shhh, don't tell anyone else but someone very knowledgeable whose name starts with the 10th letter of the Latin alphabet also mentioned that voting up the replies (if they can be voted up) can also count for the overall support.

Your wish got fulfilled :-)

Yes, really useful and probably easier to follow than the help file. Have bookmarked this topic.

One other option... if you have access to a dwg based cad program you could try moving the paperspace objects to modelspace by using the command "chspace" This will move objects from paperspace to modelspace and also resize according to the scaling of the page size/viewport. That way you could import the dwg file with everything in modelspace and then move the drawing border and other items to a sheet layer and scale them to the required size.

^This is a possibility Also, it could be that the paperspace "paper size" is way off, I've had layouts looking ok until I set a proper paper size and then found the viewport had to be scaled by a factor of 2,500 or 10,000 to make it properly sized for the actual paper size. That being said, as Jim mentioned, dwg layouts should import as sheet layers. If it does get imported then there should be sheet layers. If there are and you don't see anything then it may be a scaling issue, i.e. the actual viewport size of the imported paper space is tiny or it is quite a way off from sheet layer origin of the imported dwg file. If there is a sheet layer imported, try to do a select all and see if anything gets selected. If necessary do a zoom to selected objects to see if anything shows up at all. What also can happen is that there is a stray element on the layout which also gets imported (e.g. when copy/paste an object to the layout it gets (kilo)metres away from the origin of the viewport) causing a scaling issue as mentioned above.

@Matt PanzerNo problem, for images where only that one part is necessary this is still useful, so it doesn't hurt to mention for those not aware this is available. This export of the entire image despite using a crop thing can cause "bloat" in a PDF and possibly printing issues and not everyone knows/realises this entire image thing might be the culprit for getting large PDFs. It would be nice if VW could automatically crop the image areas outside viewports for PDFs, though there are other things that I would give higher priority if I would have to choose between this and those. Sometimes it are the convenient things that make it feel nicer to use.

@Jimglad to see you got it split up a little, as each on their own are welcome improvements to have, if this makes it more likely that at least one of these will make it than I'm all for splitting up requests. The 3rd one would be very useful to have. Would this also mean that it could be possible to adjust all radii of a polygon in one go if the request for that (listed elsewhere) would also be implemented or would it be more about moving the points of a path to be a bit easier than with NURBS paths?

It is possible that the drawing is a block (symbol in VW) which may prevent you from turning off layers (VW classes) except for the one that the block/symbol is on as all items will pretend to be in the class of the block. Occasionally it may happen that they have put the entire drawing on a layout (VW sheet layer) and then you won't see anything on your design layer. If the actual drawing is then also a block/symbol then you do have a bit bit of a problem to edit things. If you select the drawing on the sheet layer, does the OIP tell it is a viewport or a symbol? If it is a viewport then there should be items on the design layer. The design layer after import should have the same name as the dwg file you imported. What could be possible is that if you zoom to page you may not see anything because the survey is at coordinates and depending on the used coordinates it may be (hundreds of) miles/kilometres away from the origin and depending on where there could be objects a zoom to all objects may result in these objects being so small you won't be able to see them on your screen with the naked eye. In that case do a select all and you can see the extent of the objects and hopefully a few blips where you have quite a few objects together so that you have an idea of where to zoom in.

I have the same error when trying to update already installed libraries or the libraries catalog file. This happens to me on every start-up of VW2017. One way to solve this is to run Vectorworks as administrator and then you will not get the error as it will be able to update the catalog file. I've already contacted local support but they don't know what the underlying problem is.

Bump It seems the original and subsequent comments/requests have not yet been implemented, hence resubmitting the request.

Bump With roadways from polylines it will treat two ends of the created roadway as joins, but if you have a piece of roadway with curves where multiple roads meet sometimes you have to create a custom road object with multiple joins and then the issue described as above still applies. So it would be nice if some solution could be found to indicate which parts of a road object are actually joins where the "normal" road objects from VW will join the custom roadway.

Bump Any news on this request, has it been implemented or are the plans for this to be implemented for VW2018?

Bump As this issue seems a bit depending on the polylines in question (see comments above)... have any updates been made to the simplify polylines command to improve its usabiility?

Bump Has the OTF Opentype support of Vectorworks been improved or is it still the same as for 2016?

Bump

Bump

Bump

Bump, in case this has not been implemented yet. Additional clarification for the request, this is for images that cannot be cropped in VW itself to reduce the file size (e.g. aerial images) as the whole image needs to be maintained in VW. When a viewport contains a cropped part of the image, exporting to PDF still exports the entire image and therefore increases the filesize. This can be solved in a PDF editor with the reduce file size option which would then crop the underlying image to the boundaries of the page/viewport and thus reduce the filesize. It would be nice if VW could take care of this when exporting to PDF as request above.

Yes that would be useful to have as I often have fixed position for section lines relative to the model when I use them. So an option for an easy way to have section lines locked across the document would be nice.

It will be useful for (civil) engineering purposes as well so +1 (and upvoted). It might be nice to be able to save this as a resource/style that can applied to multiple viewports independent of the layer/class visibilities. E.g. one might want to show the full render of the completed project, but also a render where you see just the utilities lines, or just the structural components all from the same viewpoint.

Just filed a bug report. The file was uploaded separately from the bug report, will this automatically get linked or should I put in some reference in the file upload (did in a very general way) that I mention in both, e.g. a date and number code (20160915-01) or something like that for when you file more than one bug on a given day?

Add the option to define text height the same way as in AutoCAD, i.e. height of the upper case character instead of line height. AutoCAD defines text height as the height of the upper case characters of a font instead of line height as Vectorworks does. Upon import Vectorworks converts AutoCAD text heights to the proper line height equivalent, however it is not possible to specify the text height in AutoCAD style in a simple manner. Automatic conversion to equivalent line height would be fine, as it will then end up properly in dwg exports. Since it already works upon import of DWG files the code is already available in Vectorworks. This will make it easier to conform to text sizes specified in dwg centric offices. This ties into the request for importing/exporting text styles in dwg files

Text style import and export, where text keeps the assigned text style. Font substitution is not an issue. The reason for this request is that often project specifications or standards require the use of predefined text styles. Currently texts in dwg files exported from Vectorworks do not have proper text styles, this makes roundtrip workflows between DWG based software and Vectorworks very cumbersome if not impossible for practical reasons.