QFont::fromString() of Qt 5.x and Qt <= 6.10 rejects the >= 19 field
descriptions QFont::toString() emits since Qt 6.11, silently leaving a
broken font at every read site. Add QETUtils::fontFromString(): try the
native parser first, and on failure re-compose the legacy 10/11 field
form from the known Qt 6.11 field layout (OpenType weight mapped back
to the legacy scale) so no font information stored in existing files is
lost. Also salvage the 21 field double-serialized descriptions left
behind by some historical builds (a complete legacy description
embedded as the family name of a second one) by taking the embedded
leading description, matching what the lenient parser of Qt 6.11+
resolves them to. All font read sites now go through the helper; on
failure the default font of the caller is left untouched instead of a
cleared family.
Verified end to end on a Qt 5.15 build: a project whose 53 font
attributes were rewritten into the 19 field Qt 6.11 format loads and
autosaves byte-identical to the original legacy file (family, sizes,
bold/italic/underline, style name all preserved), and a mixed file
containing the exact 21 field string from the issue comes back
normalized as "Caladea,9,-1,5,75,1,0,0,0,0,Bold Italic".
See issue #553.
QFont::toString() is not stable across Qt versions: Qt 6.11 switched to
a 19-field format carrying OpenType weights, which QFont::fromString()
of Qt 5.x and Qt <= 6.10 rejects, leaving a broken font. Projects saved
by a Qt 6.11+ build were therefore unreadable by older builds.
Add QETUtils::fontToString() composing the legacy 10/11-field
description (weight mapped back to the legacy scale with the same
closest-match table Qt uses when parsing) and use it at every site that
stores a font description in a project, element, table config or
settings file. Every Qt version from 5.15 through 6.12-beta parses this
form correctly, so files stay readable by every QET build in
circulation.
See issue #553.
Static texts (PartText) gain an optional alignment, exposed via the
existing AlignmentTextDialog behind a new "Alignement" button in the
static text editor:
- The horizontal part aligns the lines of a multi-line text relative
to each other (centered block labels no longer need one hand-placed
text per line).
- The full alignment defines the anchor: when the content or font
changes later, the selected corner/center of the bounding rect keeps
its place instead of always growing right/down from the top-left
(same prepareAlignment/finishAlignment logic as DiagramTextItem).
Format: the <text> node takes the same optional Halignment/Valignment
attributes as dynamic_text, written only when they differ from the
historical top-left behaviour - existing .elmt files are untouched and
round-trip byte-identical. The saved x/y stay the baseline-left of the
text block in all cases; ElementPictureFactory only needs the line
alignment (the anchor is editor-side behaviour), so rendered elements
match the editor exactly.
German translations for the three new strings included (qet_de stays
complete, 2686/2686).
Verified headless: a project embedding a two-line text once with
Halignment=AlignHCenter and once without exports to SVG with the short
line centered under the long one (x 102.5 vs 126.5) in the aligned
block, and identical x for both lines in the legacy block. Editor-side
anchor behaviour follows the proven DiagramTextItem implementation but
was not manually exercised in the GUI yet.
createElement() ran a full pugixml parse of the element definition for
every instance, only to read the link_type attribute for the subclass
dispatch - on a big example project (191 instances) 49 ms of the load,
measured with temporary instrumentation. The QDom definition is already
cached and the ctor uses it anyway; reading the attribute there costs
~17 ms in total, so the net win is ~30 ms - within run-to-run noise
end-to-end, but it removes an entire redundant parser pass per element.
Behavior unchanged: an absent and an empty link_type both fell through
to SimpleElement before and still do.
(cherry picked from commit d63275971f558c8ac59f35bf4d13d7e424682342)
QHash/QMap::keys() allocates a list of every key on each call, then
contains() searches it linearly - an accidental O(n) plus allocation
where a direct O(1) lookup was meant. 35 occurrences across 7 files,
found while profiling project load times (context: #553/#560).
The hot one is ElementPictureFactory::getPictures(), which runs once
per element instance on project load: on the 3399 KiB example project
(191 instances, 129 cache hits) the keys() detour cost 45 ms of the
1.34 s total - measured, not estimated; the fix reproducibly shaves
~35-45 ms off that load. The remaining call sites are UI paths
(search&replace, dynamic text model, undo commands) where the waste
scales with selection/model size.
No behavior change: for QHash/QMap, keys().contains(k) and
contains(k) are equivalent by definition.
(cherry picked from commit 0a7f8f072fa68de7c01a9fc134a4bc8e16d62062)
saveConfig() serialises Qt::AlignHCenter as the string "AlignHCenter"
via QMetaEnum::valueToKey(), but loadConfig() matched against
Qt::AlignCenter (0x0084 = AlignHCenter|AlignVCenter) instead of
Qt::AlignHCenter (0x0004). The two values differ, so the switch fell
through to the default (Right) every time center was saved and reloaded.
Add Qt::AlignHCenter as the primary case and keep Qt::AlignCenter as a
fallthrough for any config files that were hand-edited by users following
the workaround documented in issue #283.
Verified with a standalone Qt test: QMetaEnum::keyToValue("AlignHCenter")
returns 4 (AlignHCenter), which now correctly resolves to combobox index 1
(Center) instead of 2 (Right).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
clazy is a compiler plugin which allows clang to understand Qt
semantics. You get more than 50 Qt related compiler warnings, ranging
from unneeded memory allocations to misusage of API, including fix-its
for automatic refactoring.
https://invent.kde.org/sdk/clazy
When print on printer with low resolution, some lines are not printed
because to thin.
Thin line of elements : set width to 0.5 instead of 0 and set cosmetic
option to false.
Folio border and titleblock : set width to 1 and set cosmetic option to
false.
std::variant/std::visit was only introduced with C++17. Remove its usage.
We don't even need it in these cases since QColor has an implicit constructor accepting Qt::GlobalColor.
Follow-up for b69c7b1027
Compilation using MSVC fails with a C1061 error since MSVC has a hard limit on block nesting.
Refactor the code in question to use map lookups instead.
Laurent Trinques