Feature Request: Page scale can be set per-page or per-area and not just per-document

[FSG IT]

Hi,

Can we please have more options to calibrate (and save) measurement scale per-page rather than just per-document?

1. Single scale per PDF document - this is what PDF X-Change currently supports.
2. Single scale per page e.g. different scales per drawing sheet - this would be very useful and hopefully easy to implement.
3. Scale for defined area per page i.e. multiple scales for different parts of a drawing - also useful but less critical than 2.
4. Bonus option - separate x and y scales i.e. to correctly scale a longitudinal section with exaggerated scale.

This is a critical feature for our engineers to be able to fully replace Revu with X-Change.

[Daniel - PDF-XChange]

Hello, FSG IT

Thank you for the post, I should preface this by stating that Bluebeam Revu is know to break the PDF specification in many areas, to offer more functions especially for those in the engineering/design fields. This unfortunately means that most alternatives cannot compare in those areas. The PDF specification has one key reason for existing - Document stability. Since PDF is a universal format, it is critical to strictly follow this in order to ensure compatibility when other PDF application views the file. Implementing functions which go against the spec lead to risks like data loss.

Now, to address the points you have raised.

1. I am unsure where you heard that, however we do not define scaling on a document level, but only on a "per-comment" level. You can change the scale of each individual comment. Or you can define the scale you wish to use for the next few measurements you place, then switch it up as you go.
2. If memory serves from previous discussions, it is possible, but "hopefully easy" is quite off the mark, I am sorry to say. The team has confirmed the complexity for such handling already. It is something we have looked at for the future, but I cannot make any promises.
3. Definition by area is something I am not certain if the PDF specification allows, but I will look into for you.
   It is worth noting that PDF in general was not designed to be a replacement to CAD software. PDF was originally intended as a "paper replacement" to printing the final state of a document. A format which anyone on any computer can view with accuracy, so experts in various fields can share output from their specialized applications without clients needing to purchase/install their specialized software.
4. This last one is a function which has come up in the past, if I recall the PDF specification outright does not allow for this, as any measurement scale needs to be a single defined value which is able to reliably be calculated as the same distance by any software.

Kind regards,

[FSG IT]

Hi Daniel,

Thank you for the response. I appreciate what you are saying, however, purity of the spec or implementation is not delivering value to users - these features are extremely useful for engineers and the way Revu handles scales is far superior from a users perspective. I can see that you are correct about changing the scale does not change existing comments, but it is very tedious and prone to error to manually change or re-calibrate the scale each time you wish to make a new measurement on a drawing set with several different scales.

[Daniel - PDF-XChange]

Hello, FSG IT

I am sorry that you feel this way, but unfortunately adherence to the specification is more than a simple "value to the users". It is a requirement to ensure that your documents are not volatile when viewed elsewhere. I mentioned in passing the "risks like data loss". There have been countless events where something seemingly simple has lead to the entire document being irrecoverably corrupted, because it was improperly modified by a third party.
When our software interacts with such items, we do our best to translate them to something that the spec does handle, or give you an error stating we cannot properly read the file. For example, "multi-leader callouts" do not exist, so when we interact with them, the extra leaders should become separate "arrow" annotations. There is no way to define them as a single entity. It simply is not possible according to the spec, and will not change until the Spec allows it.

We do this out of necessity. If we broke the specification, we could not promise our users that the document we allow them to make serve their needs, and allow others to view the content reliably.
For this reason, we have no plans to break the PDF specification and put all of our users documents at risk in such a way. I will admit that I am operating on memory here, hence my vague statements in this regard. It is entirely possible I am mistaken for some of the points in my previous post, but I prefer to give you my honest expectation to the best of my knowledge, rather than promise something only to turn around later and inform you it is not at all possible.

Kind regards,