KTransue

Just trying to practice on something new on this Monday morning … I've read comments from those who have been more successful than me that 'if I understand how Chief does roofs, I can create just about any roof using auto roofs'. Recently I tried using auto roofs only on a complex multi-plane roof in which the visible portion of one particular plane never touches any wall. I failed. So, today I tried it on a much simpler roof over a "saltbox colonial" with a full-width front porch's shed roof intersecting the main roof's front (hip) plane. I'm failing again, this time with regard to overbuilt planes. If it helps any, I've included a quick screenshot image of the porch roof interaction, which is the at same width as the main roof (both the main roof plane and the overbuilt shed roof plane are aligned at the gable edges and both are visible from the side view). Using auto roofs, the resulting planes keep shifting the main peak to meet the porch roof instead of honoring the main roof and adding an overbuilt shed roof intersection. Any words of wisdom?

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.

@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.

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.

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.

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?

@Alaskan_Son, you never disappoint ... Very interesting ... Thanks again!

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!

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.

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.

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.

@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?

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.

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?

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?

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?

Michael, THAT's interesting! Am I about to learn something new??? I've had this discussion with CA and chased it through their ranks, and the only thing they came up with was "probably a memory issue in the printer" and that seemed likely ... until I changed the tool that's generating the PDF in the first place. I'll have to dig into that. I love learning new things!

But, Alaskan_Son, the problem is not necessarily related to Preview ... The problem also exists when sending plans to others who may not even have the Preview app. The problem is due to the generation of the PDF document, not necessarily the presentation of the PDF document.

I've experienced this for years. It is, indeed, a problem with Chief's PDF generation, which can be proven by choosing a different product to generate the PDFs. That is, if you avoid Chief's PDF generator as your selected printer and, instead, select the option to use your operating system's print dialog (near the bottom of the dialog box), you'll likely have better results. I've reported this in past versions, but the problem persists. It seems to be related to your printer's onboard memory and the amount available to handle the prints. In any case, if another PDF tool's generation of the same image prints correctly on the same printer, then the problem is in Chief's PDF generator. I simply select a different tool (or a different rendering technique) and they're fine. Note, though, that you may not even know that there is a problem at all, like what Chopsaw is describing above. It may work fine for you, but those receiving the PDF get the black backgrounds when they print. Probably wasn't the designer's issue at all ... It's Chief's ...

Or, you know, CA could establish View defaults ... Just a thought. ;-)

Thanks all. Dermot, thank you for your usual thoughtfully detailed response. Having not found any documentation on associated defaults, I assumed that was the case.

Am I missing this? Is there a way to establish preferred default settings for Saved Plan Views? That is, for any new saved plan view, I'd like the Saved Plan View "General" Specifications pre-set to my preferences.

Quite fast for me as well. No problems in Mac OS (Catalina) on a 2018 MacBook Pro. It's not necessarily the size of the structure you're designing, either. One of my current projects is a 10,000sf addition to a 5,600sf existing home, and Chief holds up well, even in that environment. Your problem may be an ugly build-up of mold, mildew, and plaque. That is, you may be dragging along a lot of content in your files, and you might need to do some housecleaning in your favorite plan files, especially if you use those as models, templates, or starters for new plans. Also, a lot of performance issues involve what you've asked the software to keep up with, like open camera tabs, or live updates in open layouts, or automatic regeneration of framing, terrain, etc. I keep my house pretty clean and, other than some dust bunnies that get caught in my socks sometimes, I'm never frustrated by a dirty environment. There are some pretty good housecleaning techniques that might help you regain control.

Looks like you've done your research, and that may lead you to just what you need. Personally, I run Chief (since X6, I think it was) natively on a MacBook Pro and am quite happy with the performance. I'm currently working on a 15,500sf residential plan, and yeah, it's taxed a bit, but I've found that simply turning off auto-rebuilds fixes most performance degradation. If you think about that, it makes sense ... If it has to rebuild everything every time you do anything, the more complex the plan, the more power is needed. Now, I just rebuild whenever I jump back over to an elevation or 3D view, and not otherwise. Other than this unusual project, my typical projects (less than, say, 4000sf) are smokin' fast on my MacBook Pro.

After investigating and trading observations with Cameron Lacombe (Chief Architect Technical Support), who diligently stayed with me trading countless replies to the end, it seems that we had both misunderstood a feature of the Mac OS regarding Function Key specifications in the System Preferences, so I’ll answer my own question by summarizing our discovery here in hope that it helps someone else … Function Key operating system-wide behavior defaults can be set in the “System Preferences >> Keyboard >> Shortcuts” dialog, allowing any Function Key to be assigned any typical behavior of the operator’s choice. On a MacBook Pro with the “Touch Bar” feature, the function keys are not physical buttons but are simply displayed on the touch bar when they are needed. The typical display shows the possible choices of any application’s current state. But, via the "Function Key" setting, that behavior can be changed to force the display of the typical function key names (F1 through F12) for any specified application. My misunderstanding was that this setting was telling the OS that the noted app could override the system's specified defaults with its own behaviors. NOT TRUE, it seems! it looks like having an application listed in the Function Keys section only changes the display of the keys, nothing more. In actuality, it is only used as a toggle so that the function keys are readily visible within the specified application. But, the behavior of the function keys is set by the System Preferences dialog, which then overrides the behavior desired by the application! Whatever shortcuts are specified elsewhere in “System Preferences >> Keyboard >> Shortcuts” are what gets used. Period. Not the way I would have written it, but they didn't ask me. Therefore, years ago when I set my function keys to do the things I wanted them to do, I was unknowingly also disabling Chief from being able to do what Chief wants to do. VERY CONFUSING, when in the middle of something and the Hotkeys don’t do what the menus say they do! The bottom line is that MacOS has a preference setting for specifying custom Function Key shortcuts, and if those are set they're simply overriding what any other application can do with those shortcuts, and there's nothing Chief Architect can do to change that; Chief merely accepts key input and performs the appropriate action. This makes no logical sense to me, so if I ever discover differently I'll try to update this answer. Your only choice, it seems, is to change your System Preferences, or change the Chief Architect hotkeys under “Tools >> Toolbars and Hotkeys >> Customize Hotkeys” to something that looks similar to what Chief menus indicate (like “Shift+F9” instead of just “F9”), but that will assuredly lead to further confusion. Anyway, be careful out there …