• Content Count

  • Joined

  • Last visited

Community Reputation

4 Neutral

About KTransue

  • Rank
  • Birthday 12/31/1957

Contact Methods

  • Houzz
    CHC Design-Build
  • Website URL
    TaoDesign.biz, CHCDesignBuild.com

Profile Information

  • Gender
  • Location
    Kansas City metropolitan area (Lenexa KS)
  • Interests
    Creating beautiful things
    Changing lives and lifestyles
    Helping others to be the best they can be ...

Recent Profile Visitors

862 profile views
  1. KTransue

    Too many dimensions

    What does it look like before you click on that wall? There are three possibilities that come to mind: (1) You've been dimensioning on quite a few layers and they're all being displayed on top of each other (though clicking on the wall wouldn't affect that), (2), as @joey_martin suggested, you've used the Auto Interior Dimension tool and it has overlapped your manual dimensions, or (3) ... I'll await your reply regarding the appearance of dimensions before you click on that wall.
  2. @Chopsaw, I’ll have to consider this in the morning. Thanks for continuing to work to determine a solution, whether or not Chief might choose to implement it.
  3. The question is no longer whether or not it’s related to transparency, but whether it might be controllable at the generation of the PDF rather than leaving it to chance as to who might be opening the PDF and attempting to print it. Rather than leaving it up to the population at large to advise their clients, subcontractors, etc, not to utilize their favorite viewers to print, a better solution to the problem might be to ensure it will print in the first place, and that may be able to be accomplished at the time of generation, if the creator already knows that their file will be distributed for printing.
  4. Putting all of the above pieces together, I believe that: 1) It definitely has to do with the transparency feature added to Portable Document Format (PDF) file type, whose very origination was for universal utility. 2) Its manifestation definitely has to do with the last product sending the print to the printer. 3) The issue can be overcome by the choice of which product will or won’t work with these files, though there is no reasonable way to force that in the distribution of files, so that shouldn’t be a necessary step. 4) The problem can probably be overcome by the product generating the PDFs if they are generated without transparency, though that’s not a desirable solution for those that want to be able to post-process PDF files. 5) The problem can probably also be overcome by Chief in a more universally acceptable way by generating the PDF file using Chief’s PDF generator (that seems to have been proven to produce the best quality file for Chief), and then also flattening the PDF file before it is saved, if that file is to be distributed and/or printed. 6) That preference could be a switchable flag in the print dialog that would allow the generation of either type of PDF; one that is suitable for post processing for a file favoring transparency, or one that is flattened for typical printing or distribution. I still hang on to my idea that this remains a problem that can possibly be overcome on Chief’s side of the responsibility wall, to generate predictably printable output for the majority of us who don’t need to post-process PDF files. Of course, I also have a firm grasp on the very real possibility that I’m full of hoo-hah.
  5. Actually, @Alaskan_Son and @Chopsaw, I'm beginning to see the light, but I'm still left wondering, then, what you do about sending those PDF files to your clients, over whom you have no control at all ... Don't they run into the very problem we're describing? That is, they have to print those PDFs, so don't they end up with black boxes too??? What do you two do to alleviate that issue?
  6. @Alaskan_Son, you never disappoint ... Very interesting ... Thanks again!
  7. As usual, you've given me more food for thought ... I'll continue pondering. Since you do post-processing of PDFs and you find PDF transparency handy, others probably do as well so it's probably not a good thing to eliminate it. Still, though, I don't have these problems with ANY other software I use except Chief, so I can't help but believe there is something that Chief Architect can be doing to alleviate the issue. For the time being, however, it seems that "work-arounds" are the tool of the day. Thank you for your insight and for adding your thoughts!
  8. Thanks for the feedback, and the encouragement about using Adobe's Acrobat Reader as a third-party app (I'm familiar) ... I'm not sure you're seeing what I'm referring to as far as the PC side's print dialog ... I'm aware of Chief's PDF "printer". I was referring to an option at the bottom of the Print dialog box under "Advanced Options" that says (see attached) "Open System Print Dialog ...", which would/should also provide the full capabilities and print sizes of whatever printer happens to be attached. Unless someone else "in the know" chimes in (@Alaskan_Son???), I'll contact Support and see if they can tell me how Chief makes use of PDF transparency.
  9. Yes, and Adobe (and it's Acrobat product) were the ones that added transparency so many years ago (the earliest report of a problem that I've read to date is from 2010), and they made subsequent changes to their PDF generation options to acknowledge the issue. And, yes, I believe that another post-processing application can adjust for the situation (many have), but I guess my biggest question would be in whether or not Chief actually uses transparency in it's PDFs in the first place, and whether or not they need to. If there is no need, then it looks like the issue could be corrected by Chief, at least where it's PDF generation is involved. I haven't tested this yet ... The following might work for me and other Mac users who have this option, and I really don't know if Chief's PC interface also presents this option (does it @Chopsaw?) ... Maybe a workaround (I hate work-arounds) would be to simply avoid Chief's PDF generation in the first place, and choose their print dialog's option to open the operating system's print dialog, thereby invoking a different PDF print generation tool.
  10. Definitely not a Microsoft issue, though I'm sure that Microsoft-related software is affected as well. My reading indicates that the problem has persisted since introducing the concept of transparency into PDFs in the first place. Further, I don't have any Microsoft software in the mix. But, let's keep brainstorming ... What the H*** is going on here?!?!?! Oh, and to answer your question ... "Preview" is the default document/image viewer on the Apple side of the wall. Based on what Michael was suggesting, I'm guessing that I could open Chief's PDF in different viewers and get different results, but the problem, as I see it, is in the basic PDF in the first place. The problem can be completely avoided if I print directly from Chief's print dialog, but then I don't have the resulting PDF to store, distribute, or return to at a later date.
  11. @Alaskan_Son Michael (especially), I'm continuing this thread, in hope that eventually it will lead to Chief Architect systematically preventing the problem in the first place. I do believe they have the ability to control whether or not this issue persists, but I could be wrong. Please let me know if you think I'm getting closer ... I was doing some more reading tonight after rushing out the door today having just printed 9 pages of virtually solid black tabloid-sized pages. I now understand a lot more than I ever thought about procrastination, the cost of ink, and "transparency" in PDF docs, and why the images sometimes end up printing as black boxes. I also now agree that Chief preserves transparency in its generation of PDF's. Interestingly, the "black box" symptom doesn't always exist. That is, my typical process doesn't change. I use CA's "Print" dialog to generate PDFs, open Preview whenever I want to print them, and send them to my printer. So, why do almost all work fine, but some not so much? That part, I'm going to look to you for help or research more another time ... But, what I did find was that the problem was introduced to the generation of PDFs a decade or so ago, and it has affected a LOT of people. I also found this little tidbit that may or may not be worth the time it took to read this, but ... does this have merit??? 'I finally discovered that the problem centered around the selection/deselection of "ISO 19005-1 compliant (PDF/A)" under the PDF Options when generating a PDF. Further investigation shows that transparency in objects is forbidden in "ISO 19005-1 compliant (PDF/A)" formatted documents.' Might this be a way that Chief could control whether or not transparency is included in their resulting PDFs?
  12. KTransue

    Text Macro for "Saved Plan View" Name?

    Thanks, Michael. Great points, and much appreciated. I was indeed trying to jump the "manual" fence, but I have to enter in the rest of the page info manually anyway, so it's fine to stick with that. I was just hoping that, within the layout page info dialog box, I could utilize a macro field that would change that value for me.
  13. KTransue

    Text Macro for "Saved Plan View" Name?

    OK. That isn't what I'm looking for. I'm looking for a way to get the name of the saved plan view in a form that I can use it in the fields available to my layout. Essentially, it would become the descriptive name in the page title. Ideas?
  14. KTransue

    Text Macro for "Saved Plan View" Name?

    Thank you ... Though, I'm not sure how to make use of that. In the layout (where I would like it), do I then query that text box's macro's value? If so, how? Or, again, what am I missing?
  15. Anyone know if there is a text macro that reflects the name of a "Saved Plan View" attached to a layout window view port? I've looked, and searched ChiefTalk, and even a general Google search, but I'm not finding anything. Am I missing the obvious?