api-issue-tracker icon indicating copy to clipboard operation
api-issue-tracker copied to clipboard

Layout API method Entity#bounds is not accurate on Formatted Texts

Open Fredosixx opened this issue 2 years ago • 8 comments

There are actually 2 issues

  1. When create a FormattedText with an anchor type (say Right, with Layout::FormattedText::ANCHOR_TYPE_CENTER_RIGHT), and then you change the style of the text via the method style= or specifying a rtf, the anchor is no longer respected. This is by the way something visible in the interactive UI.

  2. The bounds calculations are not precise in X direction. the position returned by methods bounds and display_bounds can be slightly within the text, rather than on the box rectangle.

Basically, it looks like the anchor type is only used at creation and then is forgotten. The issue, is that you cannot create a Formatted Text directly with a rtf and style. The only argument passed is a plain text.

In addition, there is no method to get the anchor type.

Fredosixx avatar Mar 14 '23 21:03 Fredosixx

Basically, it looks like the anchor type is only used at creation and then is forgotten. The issue, is that you cannot create a Formatted Text directly with a rtf and style. The only argument passed is a plain text.

Ensure that in your tests that you attach objects to the document before changing or getting properties or style attributes. Otherwise they will be set to defaults by the Document#add_entity method.

So, in the case of FormattedText used for a dimension, this would mean that the parent dimension should have already been attached to the document.

From looking at the documentation code snippet for LinearDimension#text=, the FormattedText constructor overload that accepts a start point and anchor type seems to have been meant for use with a dimension. (Note the snippet erroneously does not show attaching the dimension to the document.)

In addition, there is no method to get the anchor type.

After the text object has been attached to the document (alone or as a subpart of a dimension), try getting it via the Style.text_anchor getter.

If the text is a subpart of a dimension, then you'll need to get the substyle for the dimension's text ...

dim_style = dim.style
text_style = dim_style.get_sub_style(Layout::Style::DIMENSION_TEXT)
anchor = text_style.text_anchor

DanRathbun avatar Mar 14 '23 22:03 DanRathbun

@Fredosixx - Can you add a minimal repro code example please?

thomthom avatar Mar 15 '23 10:03 thomthom

Thomthom,

The problem is in the description, not in the code. I think your developer can take it and check with its own code.

I think users do already a lot logging problems that are anyway not solved.

Fredosixx avatar Mar 15 '23 10:03 Fredosixx

Dan's advice was very relevant.

If you add the text to the page right after creation, then the coordinates of the bounds are correct.

This is good to know as a practice, and worth noting in the API documentation.

Fredosixx avatar Mar 15 '23 18:03 Fredosixx

@thomthom Can you add a minimal repro code example please?

@Fredosixx If you add the text to the page right after creation, then the coordinates of the bounds are correct.

@thomthom This issue was previously reported in the public forum, viz:

My reply led to opening the following issue, which contains both reproducible incorrect and correct snippets:

@Fredosixx This is good to know as a practice, and worth noting in the API documentation.

At the bottom of Issue #805, I describe in detail how the LayOut API documentation could be improved both:

~

DanRathbun avatar Mar 16 '23 00:03 DanRathbun

The problem is in the description, not in the code.

I was reading this as the behaviour was unexpected. But you're considering this a documentation issue?

thomthom avatar Mar 17 '23 10:03 thomthom

Layout entities should not behave differently before and after beeing attached to a page.

So, either this is the intended behavior, then it should be documented with a BIG warning in the API documentation

Or, this is a bug, and it should be fixed., and in the meantime be documented with a BIG warning.

Fredosixx avatar Mar 17 '23 12:03 Fredosixx

I was reading this as the behaviour was unexpected. But you're considering this a documentation issue?

Well this issue has been known since soon after the LayOut API was released. On of the devs on the LayOut team first described the solution in the public forum (I think,) which is where I learned of it.

But (as described at the bottom of #805,) it has never been made clear in the documentation and many of the code snippets are either erroneous or fail to show the adding of the entity to the document at all. The snippets just happily show changing style properties upon objects that are not shown being attached to a document.

Layout entities should not behave differently before and after being attached to a page.

Certainly, it would make life easier for programmers.

I am aware that at least in one instance the API was changed to accept a change before an object was added to the document. I'm trying to remember what it was about. I have a foggy recollection it was about rendering model viewports... or setting the render type (raster vs hybrid, etc.)

Anyway the problem is not just about text bounds and fontface choice, it is a bigger issue across all of the API entity classes. As said in #805, the document defaults for entity classes are not exposed to the API. (They are even really exposed in the manual GUI either.) A lot of problems would go away if a coder could preset the document defaults for Entity class properties.

When it comes to styles, it is a bit easier, but again the documentation does not teach readers how to leverage the "styles are transient" power.

As an example, code can create a new unattached "cookie cutter" Layout::Style object using the constructor, and make changes to that style. Then code can repeatedly create and add entity objects to the document, afterward reusing the "cookie cutter" style so that all like entities are the same style-wise.

DanRathbun avatar Mar 17 '23 22:03 DanRathbun