Truncated labels with bitmap export

Question

Thanks a lot for your detailed answer, Michael.

It works much better with PNG, indeed. The image I get after inserting into Word is clearly readable when enlarging it to the whole page and zooming to 120%.

However, I still get truncated labels. Only one or two words here and there, but still, not very convenient. Please see the following uploads - the text is in French but you'll be able to find out the "..." in 7 different nodes:

sample graph

PNG export

Best regards,

Johan

Comments

Thanks. I can reproduce the issue and will report back next week.

Answer 1

This is a side effect of "Configuration: Cropping". This configuration works by measuring the text width and determining line breaks and text cropping (the "..." ending) according to label width (which equals the node width in your case). However, due to features such as sub-pixel rendering and text anti-aliasing, text width may differ between rendering on screen and exporting to PNG (or any other export format) and therefore line breaks and text cropping may differ, too.
E.g. suppose you have a label width of 100 and default insets (meaning a margin of 2 on each side). Suppose further the first 5 words of the label text have a width of 95 on screen but a width of 97 when exporting to PNG. Since the available space has a width of 96 (label width - left inset - right inset), all 5 words will appear in one line on screen but will be split over two lines when exporting.
Since it is technically not possible to do sub-pixel rendering and some forms of text anti-aliasing in a raster image such as PNG or JPG, there is not much that we can do to change/improve the situation.

You will need to enlarge your nodes manually such that the text also fits inside the node in the exported image.

Comments

I still think that this behaviour is a bug. It simply violates the WYSIWYG (http://en.wikipedia.org/wiki/WYSIWYG) principle. I still think that calculation of text width is not correct, even not taking line breaks / cropping into account. And this image (https://www.dropbox.com/s/ufp6k4eyyo9l5u0/yed_font_problem.png) demonstrates the problem: top element is one exported to PNG (wrong), bottom one is how the same looks on screen (OK). One can see that the dimensions of orange background rectangle are not calculated correctly.

P.S. Also URL-detector is buggy in this chat and pulls ")" into URL.

---

1. yEd does not guarantee WYSIWYG.
2. Even if it did, WYSIWYG only means "... content (text and graphics) displayed onscreen during editing appears in a form closely corresponding to its appearance when printed or displayed as a finished product ..." (first sentence in the wikipedia article you referenced, emphasis mine). WYSIWYG does not mean exact representation.
3. In any case, this problem cannot be fixed. It is technically not possible to do so. If you require a detailed (technical) explanation why this is the case, contact yed at yworks dot com referencing this post.

---

Well, I agree with you that there are technical difficulties. But on the other side have you ever heard about the case when in MS Word you see the document and it is 3 pages, but when you print it it magically becomes 4 pages? I have never. Also all lines are printed as they are shown on screen, and not re-wrapped. Via Snagit virtual printer I can print to images – never had problem with that. Where is the magic?

---

What's the point of exporting to a raster format if you don't get WYSIWYG?
By the sounds of it just using the operating systems screen shot feature would be more reliable!

---

Another my 5 cents: If the text starts to overflow on the right side, then let it be. Worth is that if words start jumping from one line to next one, the last line overflows completely.

---

Hi Johan,

This is definitely a bug.
For my chart I have found a workaround. Export the graphic with a higher scaling factor. With a scaling factor of 2 I get good results.