KTransue
-
Posts
73 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Everything posted by KTransue
-
Thanks, Michael. Yes, I know that it's a straightforward exercise for manual roof builds ... I just wanted to see where auto roofs succeed and fail. Thank you for your thoughts ... always appreciated!
-
@Alaskan_SonMichael, the term we use here is "over-built" or "over-framed". In effect, it is a roof plane that is framed -- in some part -- above another roof plane, and the second plane ties into the first plane at one or more places. In this case, both ends of the primary "salt box" roof shape are visible, as are the ends of the roof over the two-story porch that die into the other roof about ¾ of the way up to the peak. But, what I'm really trying to do is understand where the capabilities of automatically generated roofs succeed and where they fail. I've read that auto roofs can work 100 percent of the time, but my testing proves otherwise. As always, I'm happy being proven wrong ... especially when I can learn from it!
-
@solver, rumor has it that you're the master at auto roofs, so when you tell me it's not currently possible then I know I can give up. (sigh) I had high hopes that I was going to be utilizing wall settings and auto roofs for everything. I'm reminded of something Dan Baumann once taught me: "Auto Roofs will get somewhere between 0 and 100 percent of your roofs correct." haha! I do appreciate you taking the time to point me toward that link, even though the suggestion is now three years in the making.
-
Thank you for helping me think this through, but I don't want the pitch change to happen over the exterior wall ... Actually, I don't want to have to determine where the pitch changes at all. It should change wherever the two pitches come together, or it kind of defeats the whole automatic roofs thing. I'm hoping I'm once again missing something simple, like a checkbox that I didn't notice has been there for a dozen versions (e.g. "Overbuild Roof Plane? -- Yes/No")
-
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.
- 38 replies
-
- 1
-
-
- layout
- black background
- (and 4 more)
-
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.
- 38 replies
-
- 1
-
-
- layout
- black background
- (and 4 more)
-
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.
