Give folios a named real-world paper size, as the base for true-to-scale printing and the cabinet-layout scale field

[ispyisail]

Give folios a named real-world paper size, as the base for true-to-scale printing and the cabinet-layout scale field

Spun out of #723 / #410 at IBSYSLevi's suggestion — the gap below affects every folio, not just the disposition/cabinet-layout feature, so it seemed worth its own discussion rather than deciding it inside that PR thread.

The gap

A QET folio has no named page size (A4, A3, …) in mm. What exists today is a pixel extent, and export sizes that pixel extent directly:

// sources/cli_export.cpp
writer.setResolution(96);
const QPageSize page(QSizeF(r.width() * 72.0 / 96.0,
                            r.height() * 72.0 / 96.0),
                     QPageSize::Point);

So there's a fixed, working px↔mm relationship (1 px = 25.4/96 ≈ 0.2646 mm — I checked: a blank folio exports as 339.0 × 229.3 mm from a 1281 × 867 px extent), but nothing that says "this folio is an A4 sheet." Two consequences fall out of that:

1. GUI print doesn't preserve scale at all. ProjectPrintWindow::printDiagram() renders with Qt::KeepAspectRatio, fitting the content to the printer's page rect:

// sources/print/projectprintwindow.cpp:312 (and the analogous PDF branch)
diagram->render(painter, QRectF(), diagram_rect, Qt::KeepAspectRatio);

That's fit-to-page, not true-to-scale — a drawing that's "1:10" prints at whatever scale fills the paper, not literally 1:10. CLI PDF export doesn't have this problem (fixed 96 dpi mapping, no fit-to-page step), so the two export paths currently disagree on physical scale.

2. It's why the cabinet-layout scale field is a stopgap. IBSYSLevi's disposition-view scale is currently entered as "X px for Y mm" — which only has to exist as a raw px:mm ratio because the page itself was never given a real size. Once a folio has a named paper size, that field becomes a proper ratio (e.g. 1:10) instead.

Possibly the same root cause as a rendering bug, too. rsoliveir reported borderless printing crops the bottom-right corner of the title block, and traced it to the same area — the fit-to-page calc may be using paperRect() (full paper) instead of pageRect() (actual printable area), silently ignoring the printer's hardware margin. Worth confirming together with whatever changes here, since it's the same code path.

Proposal (IBSYSLevi's, restated for discussion)

1. Each folio gets a named real paper size (A4, A3, A5, Letter, or custom W×H in mm), the same concept as page setup in any office/CAD program. This is the part that's generic — it's about how frames/title blocks/pages display, independent of the cabinet-layout feature.
2. Scale becomes a real ratio. Once (1) exists, both the disposition-view scale and (if wanted) a true-to-scale print mode become "N mm on paper = M mm in reality," computed from the folio's real size and its pixel extent, rather than a hand-set px-for-mm field.

Related, and worth deciding alongside this

• The element-library scale convention. plc-user's existing front-view/thumbnail elements use a fixed 1 mm real = 2 px in the Element Editor (same convention dxf2elmt uses for DXF imports). plc-user argued this should stay a fixed convention for the official collection rather than user-editable per element, specifically so the collection doesn't end up with mismatched scales across contributors. That's a separate axis from the folio's own paper size, but the two need to agree with each other for the disposition view's ratio to mean anything.
• Whether true-to-scale printing is in scope here at all, or whether (1) only needs to exist to serve the disposition-view ratio. scorpio810's concern in Added width/height/depth properties to elements #723 (resizing title block/folio distorting the drawing) is currently avoided by keeping the disposition scale fully decoupled from folio size — worth being explicit about whether that decoupling stays even after folios get a real paper size, or whether true-to-scale printing becomes possible (and desired) once it does.

Open questions

• Does "paper size" belong on the folio (per-folio, so a disposition folio can be A3 while schematic folios stay A4) or the project (one setting for everything)? The screenshots in Added width/height/depth properties to elements #723 suggest per-folio is already assumed for the disposition-view use case.
• Custom sizes: free-form W×H in mm, or a fixed picker (A0–A5, Letter/Legal) plus "Custom"?
• Does existing content (folios sized by their current pixel extent, no declared paper size) get a default paper size assigned on load, or do un-migrated folios keep behaving exactly as today (px-only, no true scale) until someone sets one explicitly?

[ispyisail]

Looked at how other electrical CAD tools (AutoCAD Electrical, EPLAN, SEE Electrical, Zuken E3, WSCAD) handle this, since a couple of the open questions above already have an established answer in that world. Caveat up front: this is from general familiarity with how these tools work, not something just verified against their current documentation — treat it as "here's the established pattern," not a cited spec.

The short version: they all split this into two completely separate concerns, and it maps onto the two-step proposal above almost exactly.

1. Model space is always true scale, full stop. Devices are placed using real physical dimensions in real units — never a zoom level or display convenience. Nothing about editing or viewing ever rescales the underlying geometry. This is the classic CAD "model space vs. paper space" split, inherited from general mechanical drafting rather than being electrical-specific.

2. The sheet is a separate object with its own explicit scale. Each sheet/layout has a standard paper size and an explicit ratio (1:1, 1:2, 1:5, 1:10, 1:20 are the common ones) that maps the true-scale model onto that sheet for printing. Different sheets in the same project can use different scales. Nothing is derived — the user picks the ratio. That's exactly step 2 above, once step 1 (named paper size) exists.

3. Schematic symbol ≠ physical footprint, on the same device record. The schematic symbol is abstract and was never meant to be to scale. The panel-layout footprint is a separate, true-dimensioned graphic attached to the same catalog part. This is the split plc-user and arummler described (symbol folder vs. front-view/thumbnail folder) — not QET-specific, it's how the part database is structured in all of these tools.

4. The footprint carries an explicit mounting/reference point, not just a bounding box. Usually the DIN-rail centerline or a defined origin corner, so asymmetric devices snap correctly and orientation-dependent clearances (keep-out zones) can be enforced. This directly answers the placement-anchor question raised on #723 — "use the mounting point" is the established convention, not a novel choice.

5. DIN rails/ducts are parametric objects with real length, auto-tracking module count / consumed width.

6. Schematic instance and panel instance of the same physical device are linked by tag, so renaming propagates both ways — the "back-annotation" arummler compared to PCB schematic↔layout tools. Standard, not a stretch goal.

None of this complicates the two-step proposal — if anything it confirms "named sheet size, then explicit ratio" is the right shape rather than something fancier. The two pieces worth adding as named prior art to the open questions: #4 (mounting point as a first-class part of the footprint, not inferred from a bounding box) and #6 (tag-based link between schematic and panel instances), since both are currently open rather than settled above.

[plc-user]

Let's not talk about implementing things, but discuss what we want!

Seriously now:
We’re still talking about a program for creating circuit diagrams here! Since when do symbols in a circuit diagram have real dimensions in millimeters? I’ve never heard of that in all my years of professional experience!

That’s why: No correlation between pixels in the schematic and any real-world units of length! The freedom that QET gives me with columns and rows — where I can freely choose the number of points per unit — is, in my view, ideal for schematics!

Only the front views for an assembly diagram can have a scale relative to the actual component. But do we need a fixed scale between the paper printout and the component for that? I don’t think so!

How do map programs like OpenStreetMap handle this?
They display a line somewhere in the corner of the screen that corresponds to a real-world length of x meters.

That’s why I don’t see any need here to limit ourselves to fixed scales! Especially in the digital age, where plans are more likely to be exported as PDFs than printed out, I don’t see the need for a fixed scale: On my tablet screen, I can zoom in on the desired area with two fingers and see all the details!

For front views we just need to specify how many px in the Element Editor correspond to one millimeter. Then we can print assembly plates of any size on A4 paper if we add a unit of length, similar to OpenStreetMap!
The most important thing is simply that the units of length are the same in the X and Y directions — but that’s already the case!

[plc-user]

I can print the @IBSYSLevi's graphic on any papersize I want and can see the dimensions of the mounting plate and the components:

[ispyisail]

I come from a CAD world, AutoCAD, AutoCAD Electrical, Promise.e, RSwire, Solidworks. I love real scale.

[ispyisail]

Wait till we get to the A4 vs letter wars, mm vs inches :)

Lucky for me this is a French project and they invented metric :) and the world has never looked back

[IBSYSLevi]

@ispyisail
As we've already discussed, we exclude countries that don't use the SI base units anyway.
As a European, I don't understand how anyone can still not use SI units...
Especially since even in the U.S., SI units are used in science.

But then again, implementing a system that converts millimeters to inches isn't that difficult, since it's simply a fixed conversion factor. In other words, the calculations can be done in millimeters in the background.

[IBSYSLevi]

@plc-user & @ispyisail

I use programs like Word or Excel as a reference. And I actually find this comparison interesting.

Word works in millimeters (mm) based on a defined page size (A3, A4, etc.), while Excel works in pixels (px), but also in millimeters (mm) when a page layout is defined. This means that in Excel, there’s a defined ratio between pixels and millimeters.

Here’s how I see it:
For standard diagram pages, it shouldn’t matter whether the layout is specified in px × px or in mm × mm. Fundamentally, both are definitions that allow for the placement of elements, a grid, etc.

It gets much more interesting when it comes to font sizes, for example; I don’t know how font sizes currently work in QET, but in Word, for example, font size 6 is linked to a specific size in mm, since it’s always the same size on A3 or A4.
And this is how I imagine it: The page size simply defines the available space on the page, as is currently done with pixels. However, it has no bearing on the actual size of objects as they appear on a subsequent printout. In other words, elements automatically receive a defined size on a printout based on the size definition, so they are the same size on both A3 and A4.

Then, just like in Office programs, you can scale a page—for example, from A4 to A3—and the objects will become larger.

In principle, with this definition—regardless of whether px or mm is used—I would simply make the scaling independent of the page size.
This gives us the basic tool that requires a defined ratio between px and mm.

Then, elements in a layout can also be defined, for example, at a scale of 1:5, which directly determines how large the element will be on the printed page.

Something else I’d like to see added later is a customizable grid increment, similar to what’s available in KiCAD, for example.
There, you can change the grid increment yourself, such as 0.254 mm per grid or 0.001 mm per grid.

This allows you to freely adjust how precisely an element can be placed.

Currently, I see a limitation in QET here in that the grid cannot be set to less than 1 px. This is where my scaling from mm to px comes into play, since the calculation can result in values like 0.nnnn px, and elements cannot be positioned with that level of precision.

[plc-user]

Are you comparing, say, a word processor and a table-calculator to a program for drawing circuit diagrams?
In German, we say: You’re comparing apples to pears.

Why should I force something that definitely has no scale into one?

Other CAD programs have separate editors for the part that need a scale: FreeCAD has the TechDraw workbench, and KiCAD has the Footprint and PCB editors. Only there are scales based on real component dimensions.

I don’t want to give up the freedom I have with the QElectroTech schematic editor just so that someone might “abuse” it to enforce a scale that circuit diagrams definitely don’t have!

Please remember:

[IBSYSLevi]

I wouldn't say I'm comparing apples and oranges.
Every drawing tool I know uses millimeters as its ruler.
GIMP, Word (even though it's not a drawing program), and KiCAD, by the way, also allow you to define a real page size—not just in the PCB editor, but in the schematic editor as well and uses mm for the grid.

Ultimately, the point is that an electrical schematic is always needed on paper (even if it’s a PDF). Or do you provide your control cabinet builders with a .qet file to wire the control cabinet?
So in no case

And yes, I know the purpose of electrical schematic programs. And every one of them has a layout tool that can follow a real-world scale.

Therefore, I don't see any reason why we couldn't define mm as a grid.

[IBSYSLevi]

Something else I noticed:

When I want to draw a layout, I can’t specify the dimensions of the standard rectangles in mm on a blank page—for example, for the outline of the control cabinet. Currently, I can’t even specify them in px (though that could be fixed).
This inevitably means that I also have to draw the base frame as a new element, to which I can assign dimensions so that it can then be used as a base element at the same scale—though that would be a viable workaround.
Of course, this also applies to cable trays and DIN rails.

But the problem is then, that the values always have to be changed within the element and can't be freely corrected or adjusted.
The main problem, then, is also that you constantly have to convert basic units from mm to px (using a defined factor which is not a even number like 10 or so...).

[scorpio810]

https://download.qelectrotech.org/qet/elements_contrib/10_electric/biblioteca_qeletrotech_WEG/layout_painel/1.1_medidas/1.1_milimetro_tds/index.html
https://download.qelectrotech.org/qet/elements_contrib/10_electric/biblioteca_qeletrotech_WEG/layout_painel/1.1_medidas/1.1_milimetro_tds/1.3_regua_tds_200mm/index.html

[plc-user]

What are you trying to say with those links, Laurent?
Do you also mean that we do not need a fixed scale for our diagrams?
Can I interpret that you mean that a comparison with a defined ruler is sufficient for you as well?
Please share your opinion, @scorpio810!

[ispyisail]

Coming back to this after reading the whole thread — I think part of the disagreement is about scope rather than substance, and there's one piece of hard evidence in QET's own code that hasn't come up yet and is worth putting on the table.

Scope first, since I think this defuses most of it

@plc-user — you're right that schematics never had scale and shouldn't get it now. Nobody here has actually proposed that, including the Phase 0 plan above, which was explicit: scale is per-folio and opt-in, and "make schematic folios true scale" was listed as a non-goal from the start. If that scoping wasn't clear, it should have been — a lot of the pushback reads like it's aimed at "QET becomes a scaled CAD tool," which isn't what's on the table. Your schematic workflow keeps its current freedom regardless of how this lands.

The actual disagreement: does a panel-layout folio need enforced scale, or is a printed ruler enough?

Your screenshot of printing @IBSYSLevi's layout on any paper size and reading dimensions off it is real evidence — for the casual, manually-checked case. It shows the current ad hoc approach isn't broken for a one-off drawing someone reads visually. I don't think that's in dispute.

Where it doesn't hold: #723 already landed real width/height/depth data on elements — three fields, merged, on master. That data has nowhere to go without an enforced px:mm mapping. A ruler graphic drawn next to the layout doesn't connect to that data at all; there's nothing stopping the two from silently disagreeing, and no way to detect it if they do. Automatic layout generation from real component dimensions — the actual feature #723 was step one of — isn't just harder without a real mapping, it's not really possible. The ruler doesn't make that feature awkward, it makes it undoable.

The concrete evidence: QET's own export pipeline already breaks the "ruler is enough" assumption

I checked this in the code, not by argument. ProjectPrintWindow::printDiagram() (sources/print/projectprintwindow.cpp:312) renders with Qt::KeepAspectRatio, fitting content to whatever the target page size is. A ruler graphic drawn inside the layout gets fit-to-page-scaled along with everything else — so it always looks internally consistent in the exported PDF, while giving no guarantee that a physical tape measure against a physically printed sheet matches what the ruler claims. That's the sharp difference from the OpenStreetMap comparison: OSM's scale bar is trustworthy because the map is served at a known, fixed projection. QET's current export path has no equivalent guarantee — the ruler can be silently wrong and nothing would show it.

Why I think this belongs in QET rather than staying manual

Not because "real CAD tools do it" on its own — because the alternative doesn't remove the work, it just moves it onto the user, silently, on every placement, forever, with no way to notice a mistake. A folio where scale is explicit and enforced makes it structurally impossible to place a component at the wrong apparent size; a ruler-only approach makes it possible to get wrong and invisible when you do. That's the actual ease-of-use argument, not "professional tools have this feature" — the version of easy-to-use that holds up under real use is the one where correctness doesn't depend on the user remembering to check.

Net

• Scale stays opt-in, per-folio, never touches schematics — @plc-user's core objection about preserving schematic freedom is already satisfied by the existing proposal.
• The case for building it isn't philosophical — it's that Added width/height/depth properties to elements #723's data is stranded without it, and QET's current export path can't be trusted to keep a manual ruler honest.

@scorpio810 — given the scope above doesn't touch schematics at all, is opt-in per-folio scale something you'd want, or is there a reason to hold off even at that narrower scope?

[IBSYSLevi]

I’m actually not so sure anymore that a mm measurement on the pages is really necessary. I still believe that the difference between mm and px on the ruler doesn’t affect the design flexibility, but it’s definitely helpful for control cabinet layout.

What confuses me most is converting mm to px. To work around this, I added length and width as properties to the rectangle in the standard editor. (See #749)
This makes it possible to draw the control cabinet, mounting frame, or similar, and then set the scale based on that.
For the control cabinet layout, this is still a workaround, but currently a viable solution—even if, in my opinion, the mm-to-px conversions are still a bit odd.

But you should be able to use this to draw the control cabinet with the correct width-to-height ratio and set the scale of the layout sheet based on that.

By the way, have you taken a look at this feature yet, or perhaps tested it?
Please note: This feature only works with the PR that has already been submitted: #723
Any feedback on it?

I think it already offers some cool added value, even if it's not quite finished yet.
I'm not sure yet how—or even if—I should generate a side view. Theoretically, it would be possible to generate it automatically.
Right now, you still have to draw it by hand, but that ultimately results in quite a few elements overlapping...

[scorpio810]

https://qelectrotech.org/forum/viewtopic.php?pid=20310#p20310

Just use defined rules and change folio dimensions.

[scorpio810]

Gustavo @ Industrialismo use another tools for cabinet:
https://youtu.be/oTnjGtdcL6g
https://youtu.be/sXqoVGV2qWM

[scorpio810]

Kellermorph use Qcad https://qelectrotech.org/forum/viewtopic.php?pid=22923#p22923

[scorpio810]

Enzo print this folio Dimensione: 257 MB to A0

026-08-15 07:27:22.773 Info: "QElectroTech V 0.100.1-dev"
2026-08-15 07:27:22.773 Info: "Compilation : GCC 16.2.0"
2026-08-15 07:27:22.773 Info: "Built with Qt 5.15.19 - x86_64 - Date : Aug 14 2026 : 04:43:29"
2026-08-15 07:27:22.773 Info: "Run with Qt 5.15.19 using 48 thread(s)"
2026-08-15 07:27:22.773 Info: "CPU : model name\t: AMD Ryzen Threadripper 3960X 24-Core Processor\n"
2026-08-15 07:27:22.773 Info: "RAM Total : 64 GB"
2026-08-15 07:27:22.773 Info: "RAM Available : 58 GB"
2026-08-15 07:27:22.773 Info: "GPU : Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700/6700 XT/6750 XT / 6800M/6850M XT] (rev df)\n"
2026-08-15 07:27:22.773 Info: "GPU RAM : Video memory: 10240MB\n Dedicated video memory: 10240 MB\n Currently available dedicated video memory: 8915 MB\n"
2026-08-15 07:27:22.773 Info: "OS : linux - x86_64 - Version : Debian GNU/Linux forky/sid - Kernel : 7.1.8+deb14-amd64"

2026-08-15 07:09:31.553 Info: Project content built in 5.375 seconds (elements collection 0, diagrams 5.258, terminal strips 0, refresh 0.11, database 0.007)
2026-08-15 07:09:31.553 Info: Project "xxxxxx_Complessivo.qet" (263099 KiB) opened in 10.287 seconds (xml parsing 4.909, content 5.378)

[IBSYSLevi]

Thanks for the inputs @scorpio810.

I see that the described workflow generally works with second elements created separately in each case. I also see that it’s possible to create an SGK layout using another application or external tools.

But I also see something else:

Since the information needed for this is already largely available in QET, I see an advantage in being able to create such a layout directly in QET. This would eliminate the need to maintain the relevant information or symbols in a second or third software program. It would also make it easier and more consistent to implement changes later on.

The ongoing maintenance of two elements per component also represents additional manual effort. The same applies to the manual assembly, labeling and positioning of a layout. Especially for larger projects, I see potential here to reduce repetitive tasks through automation.

For me, this is therefore less a question of whether the existing workflow works—it does—and more a question of which part of the control cabinet engineering QET should handle itself and which manual steps could be replaced by automation.

If QET’s philosophy is to essentially limit itself to creating circuit diagrams and to handle further steps—such as control cabinet/SGK layouts or schematic diagrams—using external tools or manual workflows, that would also be a legitimate decision in my view. In that case, a clear statement regarding this distinction would be helpful.

My view is simply that, thanks to its existing database, QET would be well-positioned to automate such recurring tasks directly.

Especially when, for example, BMKs are generated, they would not need to be maintained manually in multiple places but could be automatically imported and updated accordingly when changes are made.

Component maintenance could also be limited to a single element, rather than having to maintain separate variants of the same component for different representations.

[IBSYSLevi]

Interestingly, the column widths in PLC Manager are specified in mm, which also results in some interesting table widths...

[plc-user]

Interestingly, the column widths in PLC Manager are specified in mm, which also results in some interesting table widths...

These so-called “millimeters” have absolutely nothing to do with any actual unit of measurement!

[ispyisail]

You're right, and it's worse than a labelling quirk — I went looking and there is no conversion behind those fields at all.

sources/editor/ui/elementpropertieseditorwidget.cpp:

m_plc_row_height_spinbox->setSuffix(tr(" mm"));   // min 4, max 30, default 8
...
sb->setSuffix(tr(" mm"));                          // column widths: min 10, max 500, default 40

Those values go into ElementData::m_plc_master_data.colWidths and come back out in partplctable.cpp as scene units, used directly:

case 0: col_widths[col] = 35; break; // Type
case 1: col_widths[col] = 25; break; // Address
case 2: col_widths[col] = 50; break; // Function

There is no mm → scene conversion between the two. Searching the whole source for 25.4 returns nothing, and there is no mmToPx/pxToMm helper anywhere — so a column set to "40 mm" is 40 scene units wide, not 40 mm. That is exactly the "interesting table widths" you're seeing: the number is off by whatever the folio's units-per-mm happens to be, which depends on the page.

The part I find most relevant to this thread: the cabinet layout already solves this properly, and does it the way the rest of QET doesn't. In diagrampropertiesdialog.cpp it pairs an mm field with an explicit scale:

auto *cabinet_layout_mm_sb = new QDoubleSpinBox(cabinet_layout_infos);
cabinet_layout_mm_sb->setSuffix(tr(" mm"));
...
auto *cabinet_layout_scale_row = ...

i.e. the user states "this many mm corresponds to this many drawing units", and everything downstream is honest about it. That works precisely because it doesn't assume a global mapping — it makes the user supply one.

So there are currently three different treatments of physical units in the codebase: an explicit user-defined scale (cabinet layout), a suffix with no conversion behind it (PLC table), and no notion of physical size at all (everything else).

That seems like a reasonable argument for the folio paper size this thread is about: it would give the one thing all three are missing — a project-level statement of what a drawing unit is worth in mm — and the PLC fields could then mean what their suffix already claims. The mislabelled suffix is arguably a small bug worth fixing on its own regardless, but fixing it needs the same missing mapping.

[IBSYSLevi]

I have a first working draft of the layout function, including the feature suggested by @plc-user; the reuse of the “Front View,” which can now be specified as a layout reference on the component and, once saved as an SVG, can also be inserted into the layout.

Insertion as an original component is planned but not yet implemented. I’m concerned that there might be a conflict with the BMK references and the BMKs already existing on the “Front View.”

Anyway, I’d appreciate some feedback on whether this is worth a pull request.

To be honest, it still needs some testing ;)

[plc-user]

@IBSYSLevi:

(...) feature suggested by @plc-user; the reuse of the “Front View,” which can now be specified as a layout reference on the component and, once saved as an SVG, can also be inserted into the layout.

You can't be serious with that, can you?
You want to create an assembly drawing using QET, and you have QET elements with front views that are declared as such. And now you're saying you want to convert them to a different graphics format just to import them back into QET?
NO way! That is NOT my suggestion!
We need to avoid maintaining duplicate sets of elements and the corresponding administrative overhead for the maintainers and the users!
For example, we could introduce a property in schematic symbols that references a QET front view, allowing us to use the elements already available in QET directly.
That’s why I’ve consistently used the same directory structure for schematic symbols and front views in “my” elements. This can significantly simplify referencing from the schematic to the front view.