Best Fit

[GoncaloBastos]

Hi there!

I've been trying to implement a couple of features on top of the existing code base and I would like to open the implementations up for debate in case it's something we might want to include in Three Mesh UI directly.

The two features I have in mind are adaptations from existing functionality in Unity:

• Best Fit: Adjust Font Size so that text fits inside a given Block, within a min/max range).

• ContentSizeFitter: Adjust a Block's height/width (I think in this case we can only really adjust the height with this) based on Text font size and length.

For the Content Size Fitter logic, I calculate the inline values, followed by calculating the lines and finally getting the total height for the given inline component and apply said height to the parent Block. Most of the logic is just recycled from the Text, TextManager and InlineManager.

Best Fit is implemented similarly, where most of the logic is just adopted from existing code. I essentially calculate the text height for a given font size and iterate until the text height fits within its parent block.

This is the iterative method:

calculateFontSize() {
    let maxHeight = this.container.height - (this.container.padding * 2 || 0);

    let text = this.text as ThreeMeshUI.Text;
    let iterations = 10;
    let heightTolerance = 0.005;
    let fontRange = (this.maxFontSize - this.minFontSize) / 2;
    let fontMultiplier = 1;
    let fontSize =
      text.fontSize >= this.minFontSize && text.fontSize <= this.maxFontSize
        ? text.fontSize
        : this.minFontSize + fontRange;

    do {
      let inlines = this.calculateInlines(fontSize);
      let lines = this.calculateLines(inlines);
      let contentHeight = this.getContentHeightFromLines(lines);

      console.log(
        "Font Size: " +
          fontSize +
          ". Error: " +
          Math.abs(maxHeight - contentHeight) +
          ". Iteration: " +
          iterations
      );
      fontMultiplier = Math.sqrt(maxHeight / contentHeight);

      if (Math.abs(maxHeight - contentHeight) < heightTolerance) {
        break;
      } else {
        fontSize *= fontMultiplier;
      }
    } while (iterations-- > 0);

    return Math.max(this.minFontSize, Math.min(this.maxFontSize, fontSize));
  }

I've also decoupled the calculation of inlines from the component's fontSize, passing the fontSize directly instead. Likewise for the lines calculation, I pass it an inlines array instead of relying on the variable in the component. Finally, the height calculation takes an array of line objects. This decoupling allows me to calculate text height without having to actually set the value in the component.

I'd love to get some feedback regarding the above method. Is there a way to optimize this further? I went with a minimization problem approach as I couldn't figure out a way to calculate the correct font size for a given width/height directly.

To give a bit more context regarding why I need these two features:

Best Fit: Some of our text is driven by a backend, meaning we can't ensure that it will always fit into a fixed size block. In this case, we would like for the text font size to be adjusted so that it still fits said block.

Content Size Fitter: In a separate instance, also regarding backend driven text, we want to list a number of items with a title and a description. The length of both the title and the description can vary widely and we want the description to appear/disappear when clicking the title. The description would appear right under the title, pushing the remaining titles further down the block. In order for the remaining items to be pushed down, we need to set the height of the description block so it matches its content height.

---

EDIT
Moved fit-content discussion to #119

[felixmariotto]

Hi, thank you for your interest in three-mesh-ui and your wish to contribute !

This feature is actually on the roadmap, tracked here: #27
@enijar I think you were working on something like this yourself, any thought about OP's work ?

@GoncaloBastos three-mesh-ui generally tries to mimic HTML/CSS API, so for what you call Content Size Fitter we should just add an 'auto' value to the width and height attributes. About your proposed Best Fit feature however I'm not sure what API would best mimic HTML/CSS, maybe adding an 'auto' value to the fontSize attribute ?

I don't know if your implementation is right or not, would you mind filing a PR with an example so we can try an actual implementation please ?

[enijar]

Looks like OP has a more concrete example than I have thus far. Happy for OP to open a draft PR; maybe I can contribute to that PR

[GoncaloBastos]

Thanks for the feedback.

I like the idea of just using the auto value on the fontSize and width/height attributes.

I can try and get an example going and open a PR for it sure.

[swingingtom]

Hey all, just wanted to share some tought on "Best Fit" proposal

@GoncaloBastos nice features, and great preview implementation.

@GoncaloBastos and @felixmariotto in the preview implementation we can notice the following variables : minFontsize, maxFontSize, 'fontSize'. If we also count something like fitFont:true in order to activate this behaviour it would be four. It would be nice to be able to activate this behaviour with only a single property on a Block or Text component, and I would like to have your thoughts about the following :

maxFont and upscaling
Is it really something we need ? When defining fontSize users already define what should be the "preferred" font size to be displayed. If the preferred font size already fits, why would we try to upscale it ? For now I have hard time imagining use cases for maxFont. If you can share some, it would help.

single property
instead of

new ThreeMeshUI.Text({
   fontSize: 0.55,
   fitFont: true,
   minFontSize: 0.45,
   maxFontSize: 0.65,
});

we could have

new ThreeMeshUI.Text({
   fontSize: 0.55,
   fitFont: [0.45,0.65] // or {min:0.45,max:0.65} it would be better at the end of this post
});

relative
in order to ease further users adaptations of their code ( changing : camera zoom, Box component dimensions, font sizes ), these new values could be relatives.
Instead of defining minFontSize and maxFontSize in absolute units would be something like :

new ThreeMeshUI.Text({
   fontSize: 0.55,
   fitFont: ["-19%","16%"] // this doesn't look nice, but at least it is relative
});

Now if a user change the container size and text fontSize, the fit would stay relative. No needs to also update fitFont property (theorically)

And if we could try to improve reading by using factors instead of string percentage

new ThreeMeshUI.Text({
   fontSize: 0.55,
   fitFont: [-0.19,0.16] // this might be confusing system unit between 0.55,-0.19,0.16
});

we could rename the fitFont property to fitFontFactors in order to reinforce the reading of them being relative and not absolute units.

at the end
If there is no need to upscale, the api could looks like

new ThreeMeshUI.Text({
   fontSize: 0.55,
   fitFontFactor: 0.19 // the fontSize of 0.55, can be reduce by maximum of 0.55*0.19
});

[swingingtom]

I only called it fitFont as an example

[GoncaloBastos]

Hi @swingingtom!

Thanks for the feedback. I think for an initial implementation we can ditch the min/max fontSize and simply have it fit to the container when we set fontSize to 'auto'.

I do like your suggestions but I wonder how we could integrate them if we just use the 'auto' value in fontSize as we wouldn't have a value to relate to, so in that case fitFont values would need to be absolute? One could support both approaches but it might get confusing for users?

I'll open a PR so we can have a concrete implementation, but do you have any suggestions regarding algorithm that calculates the fontSize?

And something that hasn't been discussed yet but will sure be a challenge: What should the behavior be when a block contains two inline components with bestFit enabled?

[swingingtom]

To share my honest-freshly-new contributor-opinion, I would like to keep fontSize :

• type to number as much as possible.
• value in absolute units.

As said, it will be a lot of "what's if" cases using :

• multiple fontSize:auto|bestFit elements within the same Block
• multiple fontSize:auto|bestFit elements x contentDirection:"row|row-reverse|column|column-reverse" within the same Block
• ...

Also, as far as I know, three-mesh-ui uses a standard unit scale (1unit =1meter) but not all users projects will have the same scale.

Having a defined+required fontSize:absoluteUnit provided might at least simplify it a bit.

[GoncaloBastos]

I'm going to open a PR as @felixmariotto asked, but in the meantime there are a couple of things I would like to continue discussing. Namely:

multiple inlines with bestFit
How should we handle the situation where multiple inlines in the same container use bestFit? What if there is third inline component without it in the same block? or even in between them? I can't really see a concrete use where this would be needed, but I thought it might still be important to discuss and find the best way to warn the user that this might not be supported.

clashing attributes
How should we handle the case where a block has either width or height set to 'auto' and one of its inline components has fontSize set to 'auto'? I don't see how we could support this, but like the above point, we should still discuss how to handle said situation.

width:auto
How would this work exactly? We only ever linebreak on mandatory linebreaks? Not even on linebreaks but instead calculate how many lines fit within the height of the container and try and break the text accordingly?

[swingingtom]

multiple inlines with bestFit
How should we handle the situation where multiple inlines in the same container use bestFit? What if there is third inline component without it in the same block? or even in between them? I can't really see a concrete use where this would be needed, but I thought it might still be important to discuss and find the best way to warn the user that this might not be supported.

Indeed. Also contentDirection might affect the computation order

[felixmariotto]

@GoncaloBastos I'm beginning to think that we will have less design issues if it's the parent that is responsible for bestFit. This way the user set bestFit on the parent and we can easily check for clash with width:'auto' and throw a warning. Also all the content would be treated equally. Not sure what the attribute name should be if we go for this, should we keep bestFit: true|false ?

[GoncaloBastos]

I think that makes sense and it would get rid of the issues regarding mixing children with and without bestFit under the same parent.

Regarding the actual bestFit logic, how should we handle multiple children? Calculate the same fontSize for all elements so that they fit to the parent? Split the space equally? I think the former makes more sense as it would make the different text components look more even.

To be honest I don't entirely understand why would we have multiple text components sharing a block. Since we draw the next inline component right after the previous one, this would be the same as just joining the strings into a single text component. I guess this is because of the InlineBlock?

[felixmariotto]

width:auto
How would this work exactly? We only ever linebreak on mandatory linebreaks? Not even on linebreaks but instead calculate how many lines fit within the height of the container and try and break the text accordingly?

Consider this HTML/CSS fiddle.

The red div is always width: fit-content, which by the way may be a better API than "auto". In the first example the inlines break only when it's mandatory, because there is no parent constraint on the red div. In the second example, the red div width is reduced to fit inside its parent, hence the inlines must break to fit inside.

So basically I think that in three-mesh-ui, when the layoutUpdate cascades through the component hierarchy and encounters a component with width: 'auto' / 'fit-content' (note that it might be the root component), it must:

1. keep track of its maximum dimension based on parents with absolute dimension.
2. loop through children (and inlines if necessary) to get its content dimension, which should mean also pre-computing inlines layouts.

This way when doing 2), InlineManager knows the maximum line width and break lines when necessary (or when mandatory if no maximum line width).

If the content must overflow the maximum dimensions, it should overflow in priority from the bottom like what we can see in HTML/CSS, see fiddle.

In my opinion this feature is not trivial to implement, it should be done in a separate PR from bestFit.

[GoncaloBastos]

Agreed regarding two separate PRs as the features are quite different.

[GoncaloBastos]

So basically I think that in three-mesh-ui, when the layoutUpdate cascades through the component hierarchy and encounters a component with width: 'auto' / 'fit-content' (note that it might be the root component), it must:

1. keep track of its maximum dimension based on parents with absolute dimension.

How would the absolute width be calculated if root width is set to 'fit-content'?

Should I rename this discussion to just best-fit and open a new one for fit-content?

[felixmariotto]

How would the absolute width be calculated if root width is set to 'fit-content'?

In this case there would be no maximum width for this root component, the content could take all the width it would need. Inlines would only break when mandatory.

Should I rename this discussion to just best-fit and open a new one for fit-content?

Yes it would be best I guess

[GoncaloBastos]

done 👍

[GoncaloBastos]

@felixmariotto

I have a couple of questions regarding bestFit:

enable/disable behavior

When we set bestFit:true, I think the expected behavior is pretty straight forward. We adjust the fontSize to fit the container.

However, when setting it to false (after it being true), should the fontSize remain what it is or revert back to the 'original' fontSize? If so, we would need to store the original fontSize value somewhere. Would it just make more sense to leave fontSize to whatever value it currently is and delegate the responsibility to adjust fontSize to the user in that situation?

What updates should we trigger when setting this attribute? parsing and layout I'm guessing? However, when we are disabling it and if keeping the current fontSize, then we can skip both parsing and layout. In set it would then look like this:

case "bestFit" :
    if ( this.isBlock &&  options[ prop ] == true ) { 
        parsingNeedsUpdate = true;
        layoutNeedsUpdate = true;
    }
    this[ prop ] = options[ prop ];
    break;

If we do want to store the original fontSize, we would get rid of the second part of the if statement..

when to calculate fontSize

This calculation needs to happen before updateLayout is called right? I think parseParams is called before updateLayout, so it could be a good place to run this logic?

In this case we would also need to call parseParams on the block if any of these attributes change: width, height, padding, letterSpacing and interline (don't think I'm forgetting anything).

parseParams would look like this in Block:

parseParams() {

    if ( this.bestFit ) {

        // We only need to run this logic if at least one child is a Text object.
        if ( this.children.find( child => child.isText ) ){
            this.calculateBestFit();
        }
    }
}

I still need to figure out the best place for the actual best fit algorithm. The current implementation needs to compute the following information for each text child: inlines based on 'fontSize' and 'content' -> 'lines' based on the previously computed 'inlines' -> 'text height' based on previously computed 'lines'.

Most of this is already implemented one way or another inside Text and InlineManager, but it is not implemented in a way that would allow us to iterate over it to find the bestFit, since 'inlines' are generated when 'parseParams' is called, which is only called on update. Perhaps we could decouple the 'inlines' logic from 'parseParam' so that we can recalculate the inlines of a Text component at will?

border radius

having rounded borders reduces both the usable width and height of the block. Should we take that into account in our calculations or let the user just set an appropriate padding value?