jan15

I found that list of non-unicode Greek fonts that I saw before: Aisa, Aristarcoj, Galilee (also Bold and Italic), and SPIonic. They're all TrueType fonts, and they're all available for free download from internet sites.

Sorry. I'm on Windows only. But I thought TrueType fonts work on Mac OS. That's what it says here: http://www.myfonts.com/support/help_install_mac.html#installosx You have to re-start VectorWorks after you install a font. VW only reads the list of installed fonts when it starts up. Maybe that's the problem? And since "Symbol" isn't a Unicode font, you probably have to tell the Operating System to read the keyboard input as it would for English, the same as when you type on this forum. That's because the code numbers that "Symbol" uses for Greek letters are the same ones that Unicode uses for Roman letters. If "Symbol" doesn't work, you could search the web for other non-unicode Greek fonts. I've seen some before, but I can't remember what they're called. They were probably all TrueType.

You can re-size a group just like any other object, in the OIP, or using the Scale Objects command, or by grabbing a corner or mid-point handle and dragging it. And as with any other object, you have to be careful if you don't want to change the shape. The easiest way to be sure of changing size but not shape is with the Scale Objects command, selecting "Symmetric". For re-sizing, and for selecting and many other purposes, the size and shape of a group are the size and shape of the smallest rectangle that could enclose all the objects in the group. But not a rotated rectangle. The smallest rectangle aligned with the X and Y axes.

If you need a certain font, with accents and breathing marks, you could write it in another program, export a jpeg file of it, and paste that into VW. If not, you can use a font that assigns the basic character set to Greek letters. Before unicode, I used to use a font called Symbol.ttf, which comes with Windows and with Microsoft Office. It has only Greek letters, so you'd have to change fonts to change to Roman letters. But you can change fonts in the middle of a VW text entry. Another problem is that some of the key assigments for Symbol.ttf are different than for unicode.

Kalos orisate. I don't think VectorWorks supports the extended character set of unicode fonts. I know version 11 didn't. I remember reading a forum discussion about it. And I don't see anything about unicode in the manual of new features for version 12: http://download2.nemetschek.net/www_misc/new_in_12.pdf Have you heard that it does support unicode? I know Autocad never supported unicode, till the new 2007 version. This forum used to support unicode, but not now.

Over the top? Like in a bar-room? Where you pretend you're so drunk you don't care what happens to you? To scare people into thinking you might do anything -- maybe start throwing stools around, or break a beer bottle and try to cut someone with it? Interesting approach. But how was that going to work over the internet?

Arch.Ken, It wasn't only your title that made me think the discussion had two sides to it. It was also your initial question "Can something as basic as this still be a bug?", as well as later comments by others, including Islandmon's comment "No bug". As I read, I developed an impression of the AKA, which I confirmed didn't occur in earlier versions, as something that began when a change was made in the offset tool, presumably to correct some other anomaly, perhaps relating to offsets of polylines with complex curves. The new algorithm turned out to have an unintended result, which went undetected for a long time because it's so rarely that anyone both incurs it and has reason to be concerned about it. My first "slap", as you called it, was directed at MJW, who took it well, I thought. He didn't agree with me entirely, but saw my point, and in any case didn't call me names. It wasn't directed at you, and it wasn't an attack on anyone's character or intelligence. It was an attack on an idea, which is what a forum is all about. I still haven't engaged in any personal attacks on you or anyone else. If you want to do so, that's your prerogative. I just think it's counterproductive, and I'm going to call attention to that as I would to any other flaw that I see in an argument. What you called my "second slap" wasn't a slap at all. My apology for misinterpreting your title was genuine, and anyone can see why I might have made the mistake, given your puzzled tone and the fact that it took a lot of discussion to finally label the AKA as a bug. My offer to see a therapist was tongue-in-cheek, but it was a polite and temperate response to someone who openly tried to insult me and belittle my intelligence. I assumed that you were caught up in the heat of the moment, the "hubris" as I said earlier, and otherwise wouldn't have made an overt personal attack, so I responded with humor to give you a chance to cool off and take another approach.

David, The problem (which for brevity we could call the Arch.Ken Anomaly) only occurs when you offset a polygon that has an edge that's shorter than the offset distance. That's how you can watch for it. The only way to be sure it's occurred is, as you suggested, by dimensioning the offset-from-imaginary-extension-line and seeing that the value isn't what you intended. Perhaps in the past the OFIEL never seemed important to you, and so you didn't dimension it and didn't discover it. That may explain why someone as "passionate about the software" as Arch.Ken didn't discover it sooner, and it may also explain why NNA didn't find the problem and correct it sooner. And that difficulty in detecting the AKA, even among passionate users, is the reason why I called it "trivial", not out of disrespect for its discoverer. On the contrary. I, too, am a detail-oriented person, and have great respect for people who can find a pea under the mattress that even I didn't notice. I enjoyed the discussion about exactly what sort of pea it was, and whether it was in fact a pea or just a part of the mattress. I just thought it got a little out of hand when MJW criticized NNA - very sharply, I thought - for not correcting it sooner. I thought he "overreacted", as he suggested later I thought that the criticism of NNA was an overreaction, but a natural result of the hubris that we detail-oriented people often feel when we get a chance to engage in such discussions. I hope noone was offended by the term "techno-geek". If you re-read the sentence you'll see that it refers primarily to me. It only applies to others if they agree that the subject matter was trivial (perhaps I should have said "esoteric") and yet found the discussion as interesting as I did.

Agreed. A good place to start would be to point out what's wrong with specific comments I made, rather than ignoring those comments and the level of study they imply, and saying that I "presume to know this entire discussion by just looking at the title". And I agree with litebrite, also. Disagreement and debate are fundamental to a forum, but it doesn't seem productive to counter an opinion by saying that it evidences mental impairment in its proponent.

An opening, covered with a plug, to allow a repairman to put a "plumber's snake" (metal tape) into the waste pipe system, to break through solids that are blocking it.

Does that mean being able to view the 3D virtual model in any CAD program?

Ken, Sorry that I misinterpreted your choice of title for the thread. I'll consult a cognition therapist to try to do something about my serious comprehension problems. The discovery I was referring to was the discovery that the anomaly you described does indeed exist. Only one contributor, Mike Oz, said that he already knew about it. Islandmon may also have known, but didn't consider it a bug, at least initially. I couldn't tell whether the ongoing process of shared discovery changed his mind. All the other contributors appear to have been confirming and/or enlarging upon your discovery, which appears to have been new information to them. My point was that it's unfair to complain about failure to quickly fix a problem that hardly anyone knew about, and that if it was unknown for such a long time it can't be terribly important. I have, in fact, used VectorWorks quite a bit. If I seem new, it's because I'm too shy to have contributed much to this tech board. And I have used the Offset tool a lot, and nearly always with polygons, but I've never gotten into trouble because an edge was not accurately offset the specified distance from the imaginary extension of the corresponding edge in the original. If I were designing for the milling machines Pete mentioned, I may well have suffered consequences from this anomaly, in which case I would have submitted a bug report, or else would have made a mental note to adjust the offset polygon whenever an edge in it is not directly opposite any part of the corresponding edge in the original, in case that ever happens again. I agree with you that it would be preferable for software to have no bugs. But an architect can't pass on his responsibility to the software manufacturer, as I inferred (probably incorrectly, given my serious comprehension problems) from MJW's comment that "...I would be sued and if it is an NNA error, and a known error, my insurers would want answers." VectorWorks has bugs. So does any software. Some of them get fixed, hopefully the most critical ones. If your own work is of micro-surgical precision, you can feel superior to NNA. What I've seen in my own and other architects' drawings, supplemented by candid reports from construction workers, suggests that few of us are in that position.

MJW, it's unfair to say that NNA has taken "so long" to rectify "such fundamental issues". The problem described here is so trivial that almost noone knew about it, in spite of its being around for "so long". The person who started the thread wasn't even sure it's a bug, and there were highly intelligent arguments that it's not a bug. This thread has been interesting reading, from a techno-geek point of view, but that's mainly because the discussion was an ongoing process of discovery. It's useful to know that this unexpected behavior exists, so that we can work around it. But if it's never fixed, I for one won't care, and most users probably won't ever know. Also, the idea of blaming the CAD program for errors in an architect's drawing makes as much sense as blaming a draftsman or the manufacturer of the plotter paper. We're licensed and paid to oversee the process and to make sure the end result is correct.

Alternatively, you can keep lineweights and colors just as in the VW file, by not selecting "Map Lineweights to Colors". In that case, tell the AC user to select "None" as the plot style table. CTB and STB files are actually not needed in AC now. It can work in WYSIWYG mode if the user takes the time to figure out how.

Or you could use a macro utility to make the * key on the numeric keypad produce the ' character in VW. Then you can type 12'9 all on the keypad.

Yes, that's the problem. Symbol insertions don't really have attributes. Each object in a symbol has its own attributes. You can go into the symbol and change any or all of those, but then you'll be changing the symbol definition, and all other insertions of it will reflect the same changes. If you want to change just the one insertion, you have to convert it to a group first.

Basically, what's needed is a DWG file in which all the intersections are precise, with no gaps or overlaps. Sketchup has difficulty distinguishing between an intersection and an endpoint that's very close to it. And it has no built-in way to get rid of such problems. If the "Label Stray Lines" script works the way Fullmer describes, that would help; but I have no experience with it. In a VectorWorks plan, the easiest way to ensure that all intersections are precise is to draw everything as polylines. If you've already got a plan made up of lines, you can use the Compose command, which will convert all lines with precise intersections to polylines. That can serve as a test, and you can use the Join command to correct any intersections that aren't precise. DWG's always come into Sketchup as lines only. You make a surface appear by re-drawing any of the lines that form its boundary. That doesn't always work. It may help to erase the line first. Fullmer says you can create all the surfaces in one fell swoop by using the "Make Faces" script, which I've never heard of before. If it works as described, it'll save a lot of time. I don't know why Fullmer thinks it's important to get rid of duplicate lines in the DWG file. Maybe they are one of the reasons why surfaces don't always appear when they should. I don't know much about this, because I don't often go to all the trouble that's needed to bring a DWG file successfully into Sketchup. I always start out in Sketchup, drawing the plan there. SU is actually pretty good at that. After creating the 3D geometry in SU, I export 2D views of it to DWG. Apparently you can use VectorWorks 12's Sketchup plug-in to bring the 3D model directly into VectorWorks (I don't know because I don't do 3D work in VW). Either way, it shouldn't involve all the extra work that the DWG to SU transition does.

quote: is there any DWF view for macintosh I don't think so. Autodesk promised a free Mac DWF viewer in Sept '03, but apparently they only did that so as to discourage anyone else from working on one. But here's a company that claims to sell a browser plug-in for viewing DWF files, which they say will work on any platform because it's Java-based: http://www.cadviewer.com/

You can't open them in Autocad either, in case that makes you feel any better. That's why people create DWF files -- to prevent anyone else from being able to edit their drawings. It's just Autodesk trying to displace Adobe Acrobat. But there's a free viewer, available at http://usa.autodesk.com/adsk/servlet/index?id=2404513&siteID=123112 There's even a free DWF printer, in case you want to make your own and send them to the colleague who stuck you with them, instead of PDF files. And if you want to try to circumvent the process, do a Google search for "dwf to dwg converter". I haven't tried any of those yet, but it looks like people are making the effort anyway.

For those of us still using VectorWorks for 2D drafting only (or am I the only one left?), the problem with importing from Sketchup is the millions of tiny lines in a Sketchup DWG export file. SU is great at exporting plans, elevations, and sections, which could then be turned into construction drawings in VW. But, unfortunately, every line in the DWG file is broken at every intersection. In order to work with it efficiently in VW, all the co-linear line segments need to be joined into long, unbroken lines. Google should fix this, but they have little incentive to do so since there's an Autocad command that can convert a whole file at once. VW's Compose command can combine those tiny lines into polylines with millions of tiny segments, but that doesn't help in this case. A special Sketchup Cleanup command is needed. This is one case where Autocad has a significant advantage. It's the only case that I can think of offhand, but it's crucial to anyone who models in SU and then switches to 2D for construction drawings. It would be worth paying extra for, in case anyone thinks they can do it with VectorScript.

I've always been surprised at how small PDF files come out. Much smaller than the files they're created from. I use pdf995. http://www.pdf995.com/ And Foxit Reader to view PDF files, because it opens in a small fraction of the time that Acrobat Reader takes. http://www.foxitsoftware.com/pdf/rd_intro.php

Pete, I haven't noticed any problem with dimensional accuracy of straight line geometry. But there's a huge problem with curves, which Sketchup simply can't draw. It draws straight-line approximations, which can become a nightmare when you try to do anything else with the circle or arc or extrusion thereof. When importing to VW, you have to re-draw any curves and anything that intersects them. And forget about any kind of irregular curve. Another problem when importing is that Sketchup's 2D DWG export files have all their lines broken at every intersection, so you get millions of unusable tiny lines. There's an Autocad "Express Tool" called "Overkill" which fixes that (joins all the tiny lines into long straight lines), but I don't know of anything like that in VW. I don't know what happens with 3D imports because I'm too lazy to learn 3D CAD. Since you obviously aren't, I would guess that you're better off staying with VW 3D, or at least moving to it early in the process. Sketchup is quick but messy.

8 is the height in inches. 18.4 is the weight in pounds per lineal foot. The flange width for an S8x18.4 is 4"

quote: ...design in 3D without making preliminary sketches on paper... Yes, in Sketchup... from almost the first day that I started using it. I do it even while discussing a design with someone else, and while studying details for construction drawings. I haven't used tracing paper in 4 years. I used to enjoy hand sketching, and cardboard modelling, too. But it's easier in Sketchup, and I'm lazy. Trying to design a building with 2D sketches now seems painfully difficult.

Ironic, isn't it? Ten years ago, Minicad/VectorWorks owned that word. It would have been hard to imagine anything more intuitive.