A couple of points:

• Although the majority of basic labels will be written as one chunk, there is no guarantee. If the label has multiple formats or fonts within its text, or the text goes over multiple lines, it will most likely be written in multiple chunks.
• Although this does not apply to labels, it is worth mentioning that for some other displayModel text, if it is highlightable or selectable, and the selection/highlight changes, this will break up the text into smaller chunks.

I think I would like to see a new constant added. I feel that this usage of readingChunk is not really matching what readingChunk was originally for. I think calling it something like displayChunk is fine. I can't see how you could realy use it logically without knowing that you were dealing with displayModels anyway.

* Although the majority of basic labels will be written as one chunk, there is no guarantee. If the label has multiple formats or fonts within its text, or the text goes over multiple lines, it will most likely be written in multiple chunks.

Correct. I think cases where font weight, color or size differs for a single label are very limited. There is the multiple lines label though, indeed.

* Although this does not apply to labels, it is worth mentioning that for some other displayModel text, if it is highlightable or selectable, and the selection/highlight changes, this will break up the text into smaller chunks.

Thanks for pointing this out. So, I assume you're saying that if a piece of text is written in one large single chunk, and a part of that text is highlighted at some point, that that causes a split of the chunks, and that splitting continues if the highlight moves again, resulting in increasingly smaller chunks?

I think I would like to see a new constant added. I feel that this usage of readingChunk is not really matching what readingChunk was originally for. I think calling it something like displayChunk is fine. I can't see how you could realy use it logically without knowing that you were dealing with displayModels anyway.

This makes much sense. IN fact, I had a previous implementation where I used a separate constnat. I will add such a constant again to the current pr.

@michaelDCurran I updated the title and description of the pr accordingly.