Jump to content

Petri

Member
  • Posts

    2,011
  • Joined

  • Last visited

Everything posted by Petri

  1. quote: Originally posted by PeterT: Petri, What version of Illustrator are you using, and and when you say "fully editable", do you mean it comes in as a Vector drawing with objects that can be moved about individually, deleted or modified? As individual vector elements that can be moved, deleted etc. into ancient Illustrator 7.
  2. I just did an EPSF export from VW 9.5 on Mac OS X and took it into Illustrator. Fully editable, no problems. Well, fonts did not export, but I had used TrueType fonts in the file. Your several consultants - well, I don't know what their problem is because I have used Illustrator hundreds of times to touch up VW graphics.
  3. quote: Originally posted by P Retondo: Toggling "scale text" in my layers options does not affect this behavior. You aren't doing anything wrong and the behaviour is not a bug - I believe this is how it is designed to work. Whether it is good design, is another issue. I can't even guess whether the behaviour can be changed. The 'scale text' toggle is not actually a layer option, but rather tells the program whether to change text size when the scale of a layer is changed.
  4. quote: Originally posted by Petri: quote:Originally posted by P Retondo: i think there are two much better alternatives: 1) to use only the "None" class when bringing in automated or imported objects; or, Which is 'no classes' To continue: I am not sure how well this would work. It would then be left to the user to reclassify everything in every symbol. Even 'bad' class names are better than no classes at all in complex symbols. I have quite enough experience in editing imported symbols (or AutoCAD files without layers) to have this opinion. A typical case has been furniture.
  5. quote: Originally posted by P Retondo: i think there are two much better alternatives: 1) to use only the "None" class when bringing in automated or imported objects; or, Which is 'no classes' quote: 2) presenting a dialog box giving the user options about how to set up a class structure for the object - a more powerful option.Theoretically a good idea, but before one knows how a symbol is constructed, not really a goer. quote: Besides eliminating the annoyance of having to re-tailor names and attributes, either of these alternatives would prevent the time-consuming side-effect of PIO use that we currently suffer from - having to edit all of our saved sheets to properly display or hide the new classes.These (obvious) problems are caused by lack of communication & instructions - and therefore the poor user, not so much by technical reasons. I'm sure most veteran users know that I am not an apologist for NNA - on the contrary.
  6. quote: Originally posted by P Retondo: Petri, if you have 500 classes, I'm impressed No need to be: they usually come from imported AutoCAD drawings by others. quote: It's not that I don't agree that "Style 1", etc., are silly names. It's that I believe the issue is deeper than just the naming. The program is telling us what to name the classes, No, not really. You can give the classes any name you like. quote: and is also telling us that we will have these classes(and their default attributes), whether we want them or not, if we want to use a PIO. Not if you edit the lists. And the classes do not have default attributes. quote: This makes it more difficult to tailor the use of VW to each user's standard and way of working. Agreed, a bit more difficult, but only a bit. quote: By the way, this issue also goes beyond window and door parts - it applies to other PIOs, and to some of our library symbols, which drag unwanted classes into the picture when they are used. The only alternative would be to have no classes in library symbols. [ 04-06-2004, 07:12 PM: Message edited by: Petri ]
  7. quote: Originally posted by skfurn: I've been wanting to export drawings for my website in JPEG format. By far, the best results with maximum control come from a slightly convoluted process: print as PDF, open in PhotoShop, save as JPEG. In OS 9, there is the excellent alternative of using Print2Pict to create GIFs, which, for my money, are just as good as JPEGs, if not better. And if control is not a huge issue, screen shots are not a bad method, either, taken to PhotoShop or whatever you have, for cropping etc.
  8. Sorry - I disagree. I have files with hundreds (up to 500?) classes and the last thing I want is ten pop-ups with 500 classes. Control, control.
  9. quote: Originally posted by mike m oz: I still maintain however that it shouldn't be this hard. Well, ideally not, but when I have gone through the alternative scenarios in my mind, I have generally found them even worse, at least with the current PIO concept & technical structure. Since I write PIOs myself, you can bet I have thought of the matter - I don't enjoy the process any more than you do, but I can't think of a better way. One alternative would be to have text entry by typing. No thank you! Creating new classes via PIO interface does not appeal to me either. If you make that too easy, you end up with too many too easily. This stance rules, in my mind, out the seemingly appealing feature of FileMaker Pro: the author of the system may enable the end user to edit value lists on the fly. Well, as an occasional FileMaker developer, I have done this on a couple of occasions, with disastrous results. Won't do it again, not even to databases I use myself. Call me a control freak, but the current approach has its benefits as it gives at least some control and consistency, which is important in a practice with more than one person. The improvement that I would wholeheartedly support is a central depository of value lists (again, a FileMaker feature) so that in the PIO one would only need to define which list to use in what popup. Unfortunately I have the feeling that this would be a major change in the PIO architecture. I probably should have mentioned this before as a tip: in my colour/material value lists, I always have a choice called 'Special.' This I use for the unexpected colour or texture that is desperately needed in a project. Now, as comes to this famous stair and your - understandable - request for more options, well, I have two quite complex PIOs with so many parameters that the object info does not show them all at once even with 1600x1200 resolution. And boy, are they difficult to use! One can easily go over the top. In my view, there are so many more fundamental flaws and shortcomings in the stair PIO that more options is not a priority to me. On the other hand, your wish would be quite easy to fulfil: half a dozen popups (and, hey, lists for you to change & maintain) and the odd additional line of code here and there. Anyways, I'm glad I was able to help so, in exchange, I hereby nominate you as the value list editing advocate on this board. I have my hands full on the mailing list, where this question pops up (well, indeed...) at regular intervals.
  10. A better eyedropper tool is available at http://www.vectorbits.com/ Manuel Garcia de Parede has created this excellent tool and sells it for a meagre USD 10. Demo is free. It does class attributes, text attributes and wall heights. [ 03-24-2004, 06:09 AM: Message edited by: Petri ]
  11. quote: Originally posted by iboymatt: if shown to you would only take 1/2 hour. Much work could indeed be done to improve useablity of the system set up. Surely it does not take half an hour! Well, maybe if you include the time you need to think what classes you want to use, but that is another thing. Instructions are eg. in my message http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=12;t=003384;p=1#000005 You can even type the list in a word processor and copy & paste it into the value list. After you know what the classes will be, it takes a minute or two.
  12. Well, Mike, the good folks at NNA are not clairvoyants and cannot possibly guess what classes users might want to use.
  13. Well, here's what I'd do: run this script. PROCEDURE DelDups; { ? Petri Sakkinen 2000 - 2004 } VAR x, y : REAL; lName, sName : STRING; sN : ARRAY [1..1000] OF STRING; xS, yS : ARRAY [1..1000] OF REAL; sym : ARRAY [1..1000] OF HANDLE; i, j, n : INTEGER; ok : BOOLEAN; PROCEDURE MakeArrays (h : HANDLE); BEGIN GETSYMLOC(h, x, y); sym := h; xS := x; yS := y; sN := GETSYMNAME(h); i := i+1; END; PROCEDURE CheckForDups; BEGIN FOR n := 1 TO i DO BEGIN x := xS[n]; y := yS[n]; sName := sN[n]; FOR j := n+1 TO i DO IF((xS[j] = x) AND (yS[j] = y) AND (sN[j] = sName)) THEN DELOBJECT(sym[j]); END; END; BEGIN ok := YNDIALOG('Delete duplicate symbols on the active layer?'); IF ok THEN BEGIN i := 1; lName := GETLNAME(ACTLAYER); FOREACHOBJECT(MakeArrays, (T=Symbol) & (L=lName)); CheckForDups; END; END; RUN(DelDups); And you guessed it: it was written exactly to get rid of multiple plant symbols on top of each other. Other possibilities include: - a symbol accidentally placed in or moved to a location outside what you consider 'the drawing' - a symbol in a wrong, invisible class - your legend may have the symbol (this would not account for three, but as a general rule) In the database query, it is a good idea to limit the listing to the appropriate layers and classes.
  14. Does anyone have experience with Onyx Tree Pro? Issues I am wondering about are - difficulty of use - size of models The latter is especially important in large-scale projects. Then of course the trees do not have to be highly detailed, so is it possible to generate sort of 'exaggerated' foliage with less vertices or do some other clever tricks to the same effect? I hate my current lollipop etc. trees but at least they render fast...
  15. I believe you want 'duplicate by vector' ie. by distance of two user-defined points. The lack of this (and respective move) very basic function has puzzled many users - and at least one, Peter Vandewalle, has put tools for this into public domain. See http://www.vectordepot.com/PlugIns1.shtml, files Pt2Pt Copy & Pt2Pt Move. Haven't tested them as I have had my own for many years. Peter has chosen menu command approach, mine are palette tools. If they are not encrypted, you may be able to use them to create tools - that is in my view a more efficient approach.
  16. Petri

    linear object

    GetSymLoc gives you the starting point, then you can calculate the endpoint with GetSymRot & the LineLength of the PIO.
  17. quote: Originally posted by mike m oz: Surely it can't be that difficult to have them with real names rather than these generic ones. You are right - it is not difficult. Just edit the pop-up value lists of the PIOs in question.
  18. quote: Originally posted by MullinRJ: Hi Zero, Posted by the Self-appointed Non-modal Editing Advocat: You wanted to say NameClass(GetClass(FSActLayer)); No variables, just one line of code, with object-verb syntax. Beeewdiful! [ 02-28-2004, 05:32 AM: Message edited by: Petri ]
  19. Obviously you first chose the 'Entire drawing' option in 'Scale object' (by default, it is not done) and then saved your file. If you happen to remember (or can deduct) what the scaling factor was, you can of course rescale.
  20. In many cases, yes, but it requires very careful planning & lots of discipline - often also some custom programming.
  21. quote: Originally posted by ApocHalyptic: I wonder, how do you deal with import another .dxf file into an existing map file? Do you simply import the NEW .dxf file into a blank document and paste the objects "in Place" in the existing map file? Do you use any layer linking? Copy & paste is the correct method. Importing DXF/DWG into a non-blank file can cause all sorts of problems.
  22. quote: Originally posted by ApocHalyptic: Moving the objects records them at a different x,y position, thus my reason for all the extra steps insuring I do not lose the x,y information. Well, if you move the objects, of course their coordinates are changed! Don't lower the river, raise the bridge: move the print page instead.
  23. Groups are put in class 'None' regardless of the class(es) of their elements or your active class. Well, not to worry: the matter was discussed over a year ago and yours truly offered a solution in the form of a script: - the group is placed in the current active class unless - all its members are in the same class in which case the group inherits that class. If you have groups with over 1000 members, you will need to change the array limit from [1..1000] to, say, [1..10000]. Old habit from the time when MiniPascal did not release memory used by arrays: I have as small arrays as possible. Don't ditch the normal Group command if you handle very large groups: this script may be a tad slow, because it needs to do a lot more work. Hope it works! Copy between the {----------} lines, say 'Create Plug-In', click 'New', type a name (eg Super Grouper); choose 'Command', click 'Script', say 'Paste', click 'OK', click 'Done'. Then use the Workspace editor to install the command (it is in category Menu commands/Miscellaneous) and possibly a keyboard shortcut. {------------------------} PROCEDURE SuperGrouper; { ? Petri Sakkinen 2002-2004 } { -- This is freeware but you may not remove the ? notice. Use at your own risk.-- } VAR i, n : INTEGER; theClass, currentClass, prevClass : STRING; objClass : ARRAY[1..1000] OF STRING; obHd, gHd : HANDLE; allTheSame : BOOLEAN; PROCEDURE StoreObjectClass; BEGIN i := i+1; currentClass := GETCLASS(obHd); objClass := currentClass; IF NOT(prevClass = currentClass) THEN allTheSame := FALSE; prevClass := currentClass; END; PROCEDURE RestoreObjectClass; BEGIN SETCLASS(gHd, theClass); obHd := FINGROUP(gHd); WHILE obHd <> NIL DO BEGIN i := i+1; SETCLASS(obHd, objClass); obHd := NEXTOBJ(obHd); END; END; BEGIN i := 0; allTheSame := TRUE; theClass := ACTIVECLASS; obHd := FSACTLAYER; prevClass := GETCLASS(obHd); WHILE obHd <> NIL DO BEGIN StoreObjectClass; obHd := NEXTSOBJ(obHd); END; GROUP; i := 0; gHd := LSACTLAYER; IF allTheSame THEN SETCLASS(gHd, currentClass) ELSE RestoreObjectClass; END; RUN(SuperGrouper); {-------------------------------} [ 02-10-2004, 07:05 AM: Message edited by: Petri ]
  24. Instead of combining, you may also use 'clip surface'. The choice depends on the overall situation, but I have had situations when 'combine' has not worked or was not convenient to use. So, you start with a simple poly that covers the entire area of the desired poly. Now, one by one, bring the other polys 'on top' (or send the new poly 'to back') and do the clipping, until you have the set of points that are not members of any of the original polygons, so to speak... well, that is the sought poly in set theory-parlance! .
  25. quote: Originally posted by ApocHalyptic: It is certainly the best means of dealing with this problem in VW, but nothing beats a live adjustment from 100% to 0% Transparency for best visualization when overlaying. Airphotos can be tricky, and there have been many errors in the past due to subtle changes in Forest Cover. Tricky indeed - I have on occastion found 'invert' to be useful for (again) the exact purpose. Also sometimes it helps to preprocess the aerial in PhotoShop. Addition: also the colour of the poly you draw has to be carefully selected. Tasteful colours often don't work... quote: The problem is, that moving the 'class' objects destroys the x,y meter positional information imported into VW. Reposition of imported objects is often necessary since objects are placed center of the document. Still not sure what happens there. In our maps, everything is geo-referenced in the Australian Mapping Grid (flat earth x/y projection). The largest area we've dealt with was over 6700 square kilometres, centroid (pseudo-centroid!) at x=1094469.298, y=5954623.723 (metres). We've moved this and that, including the print page, changed scale, imported new data sets, copied and pasted this boundary poly to yet other data sets - you name it, we've done it - and the polygon stays put in the coordinates, so the spatial information is not destroyed. In VW 8 and earlier it was a different situation (I think), not to mention the good old MiniCAD (I know). But in VW 9, everything is hunky dory. We even copy and paste aerial photos. Not sure what your 'class objects' are. You aren't importing DXF into a file that already has data, are you? That can stuff up things seriously. [ 02-08-2004, 08:12 AM: Message edited by: Petri ]
×
×
  • Create New...