How PDFTron improves UX & adoption in Architecture, Engineering & Construction Software

Intro

Hi everyone my name is Aaron Gravesdale and I'm a solution engineer here at PDFTron. In today's webinar and I'm going to explain the role of WebViewer and PDFTron’s technology in the AEC space.

First I'm going to give an introduction to WebViewer, then I'm going to go into the importance of fast and accurate rendering within AEC spaces. Next I will talk about the importance of creating a consistent UI to improve user collaboration and how to integrate with review and approval workflows.

PDFTron background (1:49)

PDFTron started in the late 90s right around the time that the PDF specification was first published and our initial product line was a native toolkit that we developed in C++.  Initially it was a Windows toolkit but we then ported it over to Linux, Mac OS, Android and iOS. We also added wrappers for various languages you know C, C++, C#, Java, Objective-c, Kotlin and others.

A couple of years ago we took our native toolkit which we had been building up over the years to cover the entire document lifecycle -- document creation, conversion & processing, form filling, annotation, signing or redacted PDFs, archiving and more – and compiled it into JavaScript. This allowed us to provide that same breadth of functionality but entirely within the browser without having to do the processing server-side. Now customers could process documents without having to run anything native or run any sort of native plugins or native applications. This is especially important now that browser makers have started to deprecate native plugins.

Getting started with PDFTron (3:55)

Today I’m going to go through the webviewer demo – you can access it through our website documentation section by selecting web and then clicking the demo button. Once you launch our live demo, you can load up your own documents and try out many different features.

You can also visit our documentation section where you will find our guides for different scenarios for using WebViewer, including sample code, API references, and changelogs so you can see what's changed in the recent versions. You can also download the toolkit yourself and run it locally – just follow the guides and samples we have for getting started.

Digital transformation in Architectural, Engineering and Construction (5:39)

We’ve been adding quite a few new functionalities into WebViewer targeted at the AEC space. We've heard a lot from customers within the architecture, engineering and construction space that digital transformation is accelerating. There is a large need to handle documents electronically because architects or people in the field need to reference these documents all the time and especially the latest version of them.

If they don't have solid tools for working with documents electronically what we hear again and again is that end-users will fall back to printing out documents physically because that's a very convenient method for them. It tends to be easier to work with paper documents but that approach is not scalable and can be very problematic. This is especially true when you have many different stakeholders that need to access these documents on a jobsite.  What can end up happening is that different variations or out-of-date blueprints are shared leading to inaccurate information and ultimately rework.

That’s why it is so important that everyone involved can get up-to-the-minute accurate information about what should actually be built on a jobsite. By moving to a more electronic workflow you can help reduce the errors that occur during the construction process and make sure everyone is on the same page with up to date information.

Accurate rendering (7:25)

WebViewer is purely JavaScript and runs entirely inside of the browser.  When you access a document the browser downloads bytes of documents from the server. It then displays them in the browser by taking the PDF and converting that into a physical image completely client-side.

This offers quite a few advantages to other approaches where document rendering occurs when the server sends it down to the browser. The big advantage is in the quality of rendering - I have a true PDF document here and what I can do is zoom into the document and see fine-grain details that are still rendered accurately. I'm not dealing with an image that was converted from the PDF with a fixed resolution but instead I have the PDF document that can be zoomed in to whatever resolution I want.

This can be a big deal for construction documents where you might be looking at a blueprint and want to see some of the fine grain details inside of the document. If I'm looking at an image or even a printed copy that isn't large then I might miss important details in the blueprint.

Another important factor is that the document should be rendered very quickly no matter what its size. When dealing with scanned documents with gigantic images inside of them or documents with little fine grain lines inside of them it's important that we are able to start rendering the documents right away.

Cross-platform compatibility (9:25)

For users it is important for them to know that the viewer preserves all the accurate information inside of the document and renders that correctly and consistently across different platforms. WebViewer is able to do that exceptionally well because it's the same code running on whatever platform you happen to be using. And since PDFTron offers native toolkits that use the exact same rendering code that means that you can get very consistent cross-platform rendering from our different toolkits.

Here for example are very thin lines that might be rendered differently based on different viewers. A common example would be zero width lines inside of PDF documents, which can be rendered differently by different viewers. So if you use different rendering engines for different clients in your software suite then you might experience documents being rendered differently for different users. This can lead to disagreements about why certain things were built a certain way on a job site. This is why having consistent rendering across the board allows you to make sure that everyone is literally working off with the same page.

WebViewer does support mobile and has a responsive interface that's able to accommodate all user screen sizes and the both vertical / horizontal orientation. This allows you to deploy a single document rendering solution both on the web and embedded within mobile apps.

Offline mode (11:16)

WebViewer fully supports offline mode which can be especially important if users are working on job sites where connectivity might be a bit spotty. This can typically occur where internet connections rely on a Wi-Fi router inside of the trailer on the job site. This makes tricky to get consistent internet access on the job site and so it's very important to support offline mode.

Viewing performance & PDF Lineraization (11:57)

WebViewer supports a feature called linearization of PDF documents and it allows you to save PDF files so that they can be very efficiently rendered. This allows you to opening very large documents and having them be navigable immediately in your browser. Typically on underpowered PDF viewers if you open the document you might have to wait a while before you see the first page or before you're able to jump the random pages inside of the document.

WebViewer supports linearized PDF documents what it can do is be judicious about the bytes that are being downloading from the document. When we linearize a PDF document that means that the bytes for each page are all grouped together, allowing WebViewer to render any arbitrary page by just download a subsection of all of the bytes of the file. Now instead of downloading this in gigantic file and waiting for potentially gigabytes of data to stream down into the browser, WebViewer can just download that sliver of the file that it actually needs to render. As a result the overall rendering process can be much more efficient so you don't have to wait for the entire file to download before you can actually see it.

It also works much more efficiently on underpowered browsers such as mobile browsers that have a very limited amount of memory footprint.  For these browsers it becomes especially important that we not download an arbitrary number of bytes but instead we download a finite number of bytes to hold inside of the browser's memory at any time.

And this is exactly what WebViewer is able to do -- here's a 13,000 page document that we can open up and jump right to the first page.  The download occurs almost right away once we’ve downloaded the bytes for that first page.  We can start jumping to an arbitrary location in the document and as we jump WebViewer is able to discard the bytes that it's already downloaded. Now it's downloading these new bytes and can render those even as we are flipping through this gigantic document. As we browse the document the actual memory footprint of the browser can stay constant, allowing us handle very large files. Even files as big as two gigabytes can be loaded directly into the browser -- this kind of file size is not uncommon when working with construction documents especially in large scans that are faxed or large pictures that are emailed to stakeholders.

Layer separation (15:31)

In the PDF format we can support layer separation -- many construction documents have different layers baked into them different known as optional content branches in the PDF specification. What we can do with these optional content branches is to turn them off for different parts of the document when it's rendering.

For example if I were a plumber on a job site and I were using this blueprint as a way of understanding the plumbing of the building it could be rather confusing to look at all information here that comes from equipment, electrical and HVAC information. All of these extraneous lines are things that I might not need to know about as a plumber and could just confuse me and slow me down. With layer separation I am able to toggle those different layers on and off directly in the browser that simplifies things dramatically for me and I can get a much clearer view of where the relevant plumbing information

We're able to toggle these off and on without having to jump back to any sort of server-side rendering since this is all done inside of the client-side browser. When I toggle these it's effectively happening right away -- I'm not having to wait for some sort of conversion.

Text extraction & search (18:08)

One nice thing about having the actual PDF document is that if there is text on that document then we can still continue to treat it as text. For example if you have PNID information on a blueprint or you know specific that you need find within the document, WebViewer is able to support that function with built-in search capabilities. When we search for text in the document we get a list of all the results with ambient colors surrounding the text for each search hit.

We can also extract all the text from a document -- this is very useful for making the file more accessible. Specifically if you wanted to make that information available to somebody who had a or had difficulty reading, you could drive this information through some sort of screen reading program or text-to-speech solution. You could also build a full text index of a series of documents so that you can create Google across a set of files and quickly come across the particular document.

Embedded links in viewer (19:34)

Navigation performed on construction documents or submittals or other kinds of files is done through links and WebViewer does support links and bookmarks. For example in this document we have some PDF outlines baked into the document and we see that by clicking on those links we jump to a particular location in the file. The same mechanism is how we can support links within the document -- if you have a hyperlink in the file that points to another page, another PDF document or an outside URL you can jump to that main destination directly from the document.

File format support (20:41)

Besides PDF files we have support for quite a few others - inside of our demo gallery we show our support for docx pptx and xlsx files. We convert these file types directly inside your web browser – if you are on a job site and need to access a docx file, WebViewer can render them directly in your web browser. If you get scans and faxes in an image format WebViewer is able to load those directly – you can load images up and then download them again as a PDF copy.

With our server-side components we have the ability to OCR images too. You could pass in a scan of a document that has some text on it and then our toolkit can turn that into a PDF document that contains that image and has searchable text laid over top of it. So for example invoices that are faxed over can be turned into searchable documents.

We also have support for CAD files in our server-side toolkit – this gives you the ability to convert DWG, DNG, DXF, DWF, and RVT files into PDF copies that can then be viewed inside of WebViewer. This enables you to provide a consistent UI for all of those different file types – giving users the ability to zoom in, control the page layout, documents transition from one page to another, add annotations across the board and collaborate in real-time across all different document types.

UI Customization (22:52)

The WebViewer UI is entirely customizable and we will look at some UI customization that are available in this sample. What we've done is added in some extra buttons that allow us to configure our WebViewer on-the-fly. This is a feature that we've added for the showcase to mimic scenarios that users normally see. It is meant to give you an idea about how you can go about modifying this UI.

For example if we wanted to remove the download, print and text selection as a way of locking down document content – we can do that inside of WebViewer by disabling the UI items with just a few lines of code. We can also disable certain annotation tools - turnoff different text tools like freehand drawing, signatures, or eraser. By disabling these tools we can just leave a few different kinds of annotations that a user needs to work. And at the same time slim down the available annotations just to make it more user friendly – so users don't have to think as much when they are working with the UI. By giving them a streamlined user experience it keeps users from making any mistakes as they're editing the document.

Hyperlinks (24:40)

Someone was asking can we create a hyperlink and an annotation in the document and that's absolutely the case. Here we can add a rectangle annotation on top of the file and we can make a hyperlink here directly in the UI. I can then link to another page in the file or document. I could also add in a URL which makes this annotation a hyperlink that takes the user to an outside website.

Support for existing annotations (25:16)

We also support existing annotations that are already inside the document - that's something that we hear about quite a bit from clients that have an existing library of PDF documents with links that are already set up between different pages. For example if you have a blueprint on one page with links to the different pieces of equipment that need to be installed - we can support those kinds of documents out of the box so you don't have to go through and rewrite all of your PDF documents with new links.

Custom annotations (25:58)

We can also make new custom annotations - one of the simplest is just adding an approved image and making it a stamp. We can then stamp that image file and customize how it looks in the document doing things like change the opacity so that so you can continue to see the be content underneath the stamp. This is all customizable as well so you can use whatever image you like or if you'd like to make more complicated annotations that's possible - for example we have a triangle tool that we've added that demonstrates that you can make your own annotation shapes quite easily and have them behave however you wish.

We also have a variety of standard construction annotations - for example you can make cloudy annotations that lets you demonstrate to users that you know a certain area of the document needs further review.

Annotations & Custom Workflows (27:44)

One common request is to customize these existing annotations and make them more powerful. For example as you add in an annotation you might want to also automatically trigger some JavaScript code that adds a new task into a back-end workflow system. This could then communicate with other systems ensuring that everyone is on the same page about a given state on the diagram.  To give you another scenario let's say that I was I was enclosing this part of the diagram in a cloud annotation to be able to demonstrate that this is an erroneous piece of equipment and it needs to be repaired. I could then create a cloudy annotation that is specifically designed to signify a problem area or something needs to be repaired. I can then tie a given state to this task and drive collaboration which can all be controlled through custom JavaScript code that you add into these annotations.

In our latest version we've added in the ability to tie annotations to a given state. As I annotate a given document, I can go into the comment section and add an annotation state. By default we have states like accepted, rejected, canceled, completed, etc – these can all be fully customized where you can set whatever annotation states you wish unto on to an annotation.

Including annotation states can enable you to add workflows for each of these annotations once they've been added onto a document. We've seen this with some office collaboration systems that enable people to comment on different parts of the document and then have states like accepted or rejected. This can allows everyone to see the current state of each of the tasks that have been created for this document and gets everyone on the same page in terms of reviewing and approving parts of that document or tasks on the state of the job site.

Real-time collaboration (32:04)

In addition to being able to tie annotation states on to different tasks, there are other ways that we can improve collaboration between users. Comment threads allow users to collaboratively chat within documents. Each user is given a unique user ID - for example here I'm logged in as the Sally user. When Sally makes an annotation, let's say highlight some text here, a comment thread is automatically added with the user’s information. You can see we've also extracted the text automatically from the file and populated it within the comment. Now other users can come in and comment on this in real-time.

For example a “Justin” user could come in and add a comment to the thread of “let’s review this”. The Justin user could also come in and set the annotation state that indicate that the annotation has been accepted.  By setting a specific state, it allows other users to come in and review the current state of a task and determine whether something should be accepted or rejected.

You can add or modify custom states through our api's. This allows you to model what's going on in your specific jobsite and tie that in closely with what the user sees or for the steps they are given for a task.  

User permissions (34:05)

Another thing that's interesting about the way we set up this sample is that it shows some of the different permissions that are available for different users. Initially we logged in as the sally user - sally is an ordinary user and isn't an administrative user or a read-only user.

An administrative user can see and edit everyone else's annotations. In this example Justin is setup as an administrative user – this is something you would setup as a string for the logged in user. WebViewer itself doesn't do any user management, permissions, or authentication - rather gives you the flexibility to build it to suite your specific scenario.

Client-side vs server-side (35:19)

The server component is entirely optional it's really just there to speed up document display and to add support for additional file types or browser types that are unsupportable without a server-side component. The majority of time if you are running on modern browsers you can run purely client only for both the viewing, annotation, and editing documents inside of the browser.

Generally when our clients are first trying out WebViewer we recommend starting with client only evaluation. That way you're not working with a server component and can determine if client side deployment meets your users needs. If your users are running relatively modern browsers like Chrome, Firefox or Safari then typically client only operation works quite well. If your users need to support older browsers like IE then then sometimes WebViewer server is a good idea but you can certainly set up client only viewing with any browser type and then see what the performance is actually like on documents that your customers use.

Comparing documents in the AEC space (44:02)

Another feature that could be useful within an AEC space is our document diffing capabilities. We've created a sample that shows how to take three WebViewer instances and show them on the same page. What we can then do is synchronize the zoom and scrolling of WebViewer across all three instances. Here I'm zooming into this left one and those zoom and scroll events are propagated to the other instances of that viewer.

What I'm showing here are two versions of the same document - here we have the first version over on the left and the new version on the right. Then here in the middle we're doing a pixel-by-pixel image diff of the rendered versions of these two documents. You can see that anything that's been added to the new document is highlighted blue and anything that's been removed is highlighted as red. This way we can quickly see what's changed between two versions of the same document.  

The pain point that we're trying to address there is when someone on the job site gets two versions of the same blueprint and something subtle has changed between them. If they're just looking at the PDF copies or even worse just a piece of paper it might be very difficult to see what's changed between the two of them. Having the ability to diff those two copies of the document can really help make it easier to see instantly what has actually changed.

We’ve also been customizing this diff recently based on feedback from our clients. We've added in some tools to make it easier to adjust these at a fine-grained level. For example one very common case is where you have an existing blueprint and then someone has faxed you a new version of the blueprint. In situations like this the document could be a little misaligned or at a slightly different scale. So we added a tool here that lets us adjust that very slightly – you can adjust an overlaid document relative to the other by rotating as needed.  That way we can very minutely address differences between those two documents.

We've also added in the ability to create an alignment between the two documents by drawing arrows on each for the starting and end point. These are then aligned on the same page based on those arrows - one end point is matched up to this end point and the beginning of the arrow is matched up to the beginning of the arrow on the other document.  That way we can overlay two documents over each other at whatever scale level we wish, which can be very helpful when looking at blueprints that show the same thing but at different scales.

For example you might have a larger blueprint of a city block and maybe a smaller blueprint of the building that might be built on that city block. What you could do with this tool then is realign both of those blueprints so that you can overlay them on top of each other and make sure that those are in agreement.

We've also added in the ability to turn off these differences and instead change the opacity to more easily see how things have changed.  This gives you another way of spotting the differences between each document. We also have the ability to download the middle panel image so we have a preserved diff between the two.

We have other diffing tools as within our toolkit – on this sample we have a way of merging two PDF documents together so that you can see the difference between the documents

You can also do product diffing in batches - if you had a variety of PDF documents or folders of them we can programmatically go through and generate these PDF comparisons.

PDF Measurements (51:01)

Another feature that I wanted to point out was our support for measurement annotations. Here we have some of our measurement tools and if I have a blueprint I’m able to figure out the amount of material that should be allocated for various parts of the job – like getting the size of the doorway. What I can do is zoom in to that area and then draw arrows to determine the actual size of this doorway.

Notice that by default the measurement gives me the size of the PDF itself. But what I want to do is change that to the actual scale of a doorway - let's say three feet. What I do is calibrate that measurement with a single annotation. Now all of my measurements and any subsequent measurements that I'm making will also take that same scale into effect. That way if I have like a scale listing on a PDF document I can measure that directly and immediately set the calibration for measurements that I'm taking on the document.

Besides just performing a linear measurement, I can use our other measurement tools like perimeter measurements.  For example if I wanted to see the exact size of the perimeter of this room I can just go through and make a polygon annotation around it. This gets measured right away and gives me the perimeter measurement. If I wanted to measure the area of a certain part of the document I could do that through our polygon annotations. I just measure the area directly and find out that the area here is 6 square feet.

That's something that can be added to virtually any of our annotation types because they are so extensible. You could go in and change any calculation that's made to any annotation. We've also baked in the ability to snap to certain points within the document - here is a quick demonstration showing some of the different snap points that we were able to find in this particular document. We are able to extract the control points from inside of the PDF at a low level and use that to either directly give snap to points or calculate things like the midpoints of lines as places to snap to inside of a blueprint. This makes the entire process more straightforward and less error-prone when measuring directly on a PDF document.

Custom UI on github (54:51)

I should also mention that in addition to some of the customizations that I was talking about before – like removing things from the UI or adding in new custom annotations - we do have our full UI source code posted onto github. It's written in React based JavaScript and you can fork this to make changes to anything you like in the UI.  Buttons can be swapped out, reworked or rearranged based on what your users are expecting.

If you happen to have an existing UI that your users are comfortable with - you've already acclimated your end users to a particularly way of working - that’s something that we can accommodate also. In this sample we show a third-party UI that we've downloaded from github. What we can do is present that third-party UI within WebViewer or within a web page and then have our SDK do the actual rendering of that document.

Here we have a document that we're doing just that - WebViewer itself has performed the rendering of this PDF page into an image that is displayed through this third-party viewing code. What that means is that you can still support the same UI that you're viewing documents in today but with the WebViewer SDK under the hood to do the rendering or the more advanced PDF processing features. This can be a very quick way to improve the overall experience that your users are seeing without having to change anything about their workflow.

Conclusion (57:05)

From my side that covers all of the items that I wanted to get into today. We talked about fast and accurate rendering within an AEC space. We talked about how creating a consistent user interface for users can be enabled within WebViewer. How WebViewer can enable and support collaboration between different users whether they're on mobile devices, in the field or working on desktop systems.  The ability to comment with each other and collaborate in the real time and the ability to review and approve different tasks within the workflow based on locations of the document.

If you'd like to know more please do feel free to reach out to us - you can get started with the toolkit yourself by downloading it from our site. Then please do feel free to reach out to us either through our support channels or by contacting PDFTron sales team.