Home  /  Miscellaneous   /  Guest Bloggers   /  A Tale of Exploding PDFs

A Tale of Exploding PDFs

This post is by Ferenc Traser, a Product Designer at GRAPHISOFT. Ferenc has an MArch from Budapest University of Technology and Economics and an MS Arch from DAAP at the University of Cincinnati. Prior to joining GRAPHISOFT, he practiced as an architect, mainly working on historic preservation projects. Previously on Shoegnome, he wrote about the development of Point Cloud integration into ARCHICAD 19

While working as an architect, I thought of PDFs as snow globes for architectural drawings. Unlike other formats, in a PDF everything was to be seen, but nothing was to be touched inside. When I published them, my flattened building was converted into lines, fills and texts, neatly packed into a form resembling digital paper. There was no way of editing them: if you made an error-for example a layer stayed on by accident-you had to re-publish them. Strangely enough, you could not only save drawings as a PDF, you could also find it among the printing options.

When I joined a small architectural firm ten years ago, not everyone was a fan of PDFs. Most people drafted in 2D and were not aware of the benefits of a 3D model. They placed each drawing, including sections and elevations, on a story and used the marquee tool to set the drawing boundaries. This also meant that every area was different in size, with various print settings that you had to set up each time. Sometimes it was easier just to print them on paper, and if we wanted to send something to the structural engineer, they received DWGs.

My tenure at this firm lasted for a few years, but at the end everyone understood the one-click benefit of publishing instantly. City authorities also started to favor electronic copies instead of huge piles of paper. But our romantic struggle with PDFs remained: they were still considered a tightly locked form in which drawings remain untouchable.

When we needed detail drawings from a manufacturer, we looked them up on the internet or, if we were lucky, we got CDs and DVDs of their files. Even better if they included a browsable catalog to help us locate the files we needed. For each detail, there were at least two or three files: one just to look at (the PDF) and another to edit in our own software (usually DXF or DWG). If the manufacturer forgot to include the latter, we were left with the good old method of tracing the lines.

A few years later, already at GRAPHISOFT as a product designer, I started to work on a project that would make PDFs more accessible and take advantage of their versatility. The first step was to utilize layer visibility. If you placed a drawing from a DWG source on the floor plan, you could set up which layers you wanted to see. In many cases, the files you received contain loads of information you didn’t need. For example, in a land survey, initially only the topographic lines are important for creating a mesh. With PDFs, the situation can be trickier: instead of layers, they have visibility groups. Each element can be assigned to many groups concurrently, or to none at all.

We soon realized how different the PDF logic is from ARCHICAD’s, but we wanted to ensure that these differences would not be an obstacle to you, the users. We decided not to create a PDF translator, like the ones we have for DWGs and IFC. We did need a tool to bridge the differences between ARCHICAD and a foreign format, yet no one wanted something as abstruse as a PDF translator. So we spent a lot of time designing the processes that would eventually replicate PDFs in their drawing state using ARCHICAD’s 2D resources, yet without much change in appearance.

Self-intersecting polygons, fills with wild patterns, and visibility groups made our job difficult. There were bodies of text that seemed fine until we realized each letter would become a separate entity after explosion and would take up a huge amount of memory. Sometimes there were hatches that looked okay until a closer examination showed that they were indeed a set of lines. When I recently asked the project’s lead developer about this, he agreed that coding was almost easier than setting up the rules for an exploded result that would replicate the PDF’s appearance.

I remembered from my architect days that I always tried to use as few attributes as possible. When it came to merging models from other sources, I always spent some time cleaning them up. Besides keeping the original look of the PDF as much as possible, my aim with the PDF development in ARCHICAD was to utilize the project’s existing attributes as much as possible. In most cases, even annotations and dimensions are not important-only the drawing itself. You can use it as a detail and merge it into a bigger drawing, or use the surveyor’s topographic lines to create a mesh.

Besides avoiding translators and too many newly created attributes, the third idea was to make this process as easy as possible. With only one click, using an existing command, you just press OK and all is done. When we design features in ARCHICAD, we always try to refer to established processes and methods. Since we decided not to create a complicated translator, a few options should suffice. Layers, lines and fills are all we need to talk about, and sometimes also font types, if you use one font already throughout your project. Most of the conversion processes are hidden-they were thoroughly designed so that you don’t have to set them up.

After the project was completed but before its release, I presented the new features to an ARCHICAD user group and everyone was amazed. Mostly because it created a brand new technique for PDFs that was simple, yet would have been inconceivable a few years earlier. When I designed a house for a family member, I contacted a surveyor who said he could send me the PDF via email and the editable format by the time I paid for the drawings. By the time we met again, I had already modeled most of the house and its surroundings.

Designing this feature was a good experience that taught me how to deal with situations in which the process can be difficult, abstract or foreign to ARCHICAD. Most users don’t care much about the background details; they just want to design their buildings efficiently, and rightly so.

In ARCHICAD 21 we faced many more similar issues, but at the end of the day we hope we have created great new tools and features that are similarly efficient.

Did you enjoy this post from someone who helped shape ARCHICAD? Let Ferenc know in the comments. I wrote about my own experiences with exploding PDFs in ARCHICAD over on BIM engine: Why my Neighbors Love ARCHICAD but don’t know it. Subscribe to the blog so that you don’t miss future posts about the awesome future of the built environment: Shoegnome on FacebookTwitter, and the RSS feed.

Post a Comment