Text parts in the library have bounding boxes that are way too long

mMerlin commented 4 years ago

Current Behaviour

Text parts in all views tend to take up way more room (per their bounding box) than the actual rendered text content. Some testing shows that the width is being calculated as if a fixed width font was being used. Specifically, every character is being assumed to take up the same space as an em dash character. The Droid Sans font used with the text part has proportional character spacing.

When the text is placed near the edges of the view content, any exported image includes the empty space at the ends of the text element, causing image extents to expand for no visible reason.

Using the ruler tool shows that the bounding box extent matches what Inspector reports, but the visual rendered content is a little, to a lot, shorter unless the content is all em dash (— == U+2014) characters.

hello_world_lcd-bb

This is important (to me), because I export fritzing images to be included in other documents. I get much better results if I do not need to do post processing of the images. Cropping SVG images is not as simple as cropping bit map files.

.fzz and all exported svg files renamed to append .zip to the name. Just rename again to remove the .zip to be able to use.

Reference breadboard export bare_lcd-bb.svg.zip

hello world breadboard export hello_world_lcd-bb.svg.zip

Reference schematic export bare_lcd-sch.svg.zip

2 line schematic export 2_line_lcd-sch.svg.zip

Reference pcb export bare_lcd-pcb.svg.zip

connection pins pcb export connection_pins_lcd-pcb.svg.zip

Build: <e.g. Version 0.9.3 (b5c895d32 2016-04-19) Cocoa [Qt 5.12.2] app/org.fritzing.Fritzing/x86_64/stable Version: 0.9.4b Commit: c595162a1d06f01eab9b66092c7ca68518974b9887295cd59950c439bfba3a72

Operating System:

% cat /etc/os-release NAME=Fedora VERSION="31 (Workstation Edition)" ID=fedora VERSION_ID=31 VERSION_CODENAME="" PLATFORM_ID="platform:f31" PRETTY_NAME="Fedora 31 (Workstation Edition)" ANSI_COLOR="0;34" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:31" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f31/system-administrators-guide/" SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=31 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=31 PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy" VARIANT="Workstation Edition" VARIANT_ID=workstation

Steps to reproduce:

in a new sketch, in the breadboard view, delete the breadboard and place and place an LCD display.
on the pcb vew, reduce the size of the board so that it does not affect export boundaries.
export all three views to get reference images
place a text element in the breadboard view: "HELLO BIG WORLD!"; set width to 104.6mm; position to approximately line up with LCD text row;
place a text element in the schematic view, "A two line display"; leave default width of 45.7mm; position along bottom of LCD1 part, rendered text aligned to left edge of connection pins
place a text element in the pcb view, "The connection pins for the LCD"; leave default width of 78.7mm; position below connection pads, rendered text aligned to the left edge of the LCD1 part.
export svg images of all views, and compare to the reference images. Full screen sometimes shows the shifted content better.
place a new text element in the breadboard view with 16 em dash characters "————————————————"; set width to 60.3; position over a row of the LCD display.
use rulers to measure things, though simply selecting, or hovering over, the text elements shows the empty leading and trailing white space.

text_bounding_box.fzz.zip

Expected Behaviour

The bounding box should (fairly closely) match the rendered content. There are better ways to calculate text length than multiplying by the size of an em dash. Since Fritzing is using SVG images, the getComputedTextLength method should do the right thing. Assuming it is implemented in the underlying tools being used.

Even changing the text to left align would help in my (general) case. It is easier to trim blank content from the right of an svg image. Just reduce the svg element width attribute (and viewBox). Which of course would not help if the text was rotated.

KjellMorgenstern commented 4 years ago

The mentioned method is not correctly implemented, and Fritzing is jumping through quite some loops to get text sizes. This goes as far as rendering the text on a white sheet, then calculating the bounding rectangle by finding the colored pixels, just to get the bounding box. I don't mind a pull request (or better, someone fixing the QtSVG library, there is an open issue about that since >5 years), but be warned that might get a bit more difficult than expected.

mMerlin commented 4 years ago

Well, that at least points to where the issue should be fixed :)

There is "shell" code for how the length should be computed on the svg web site. But that relies on another function, to get the size of a single character, that is also probably not implemented "correctly". I assume that also means that the function to get the text length along a path does not work, though I have seen a demo using it in a web browser.

To do this properly needs to interface with a bunch of font related information. Might be able to simplify by only working with the fonts that Fritzing uses. To get close. I expect that font scaling will still make getting accurate results challenging.

I did a manual edit on a .fz file to test the alignment. Changing the 'middle' entry to 'start' worked for the general case.

KjellMorgenstern commented 1 year ago

Still an issue, just reproduced:

KjellMorgenstern commented 3 weeks ago

I have rewritten the text box calculation, to use the actual font metrics.

Fixed text box size

The text now should not move anymore when adding or removing characters. Left align, center, and right align with other items should work as expected:

Now takes variable spaced fonts into account

This works for each font, also when the font is not monospaced, like NotoSans / OpenSans in the schematic view

Fixed the baseline

This also fixes the misaligned baseline, that would sometimes cut off text: Fritzing 1.0.4 and before:

Fritzing 1.0.5 will use the fonts ascent value to determine the baseline:

Further, it will allow custom padding, but that feature doesn't yet have any priority (I think it was never yet requested)

The solution does not affect existing circuits, as long as the logoitem is not edited. As soon as a logoitem in an existing sketch is edited, the new metrics will apply, which means that the item must be manually repositioned.

Should we write a migration/position recalculation for old sketches?

In theory we could automatically migrate sketches the first time they are loaded in a Fritzing >= 1.0.5, so the position is automatically adapted. As shown in this example, this could also affect copper fills, but that would not be stopper for such a migration. Without the automatic migration, it would be annoying to work on an old project with lots of logoitems, that now need repositioning as soon as they are touched. But is it important enough? There are still > 400 issues. For part labels, we have fixed the baseline already in Fritzing 1.0.0 (almost two years ago) see bool PartLabel::migrateLabelOffset() for the migration.

fritzing / fritzing-app