Text is anchoring left when adjusting Hspace

Text is anchoring fist letter of each row when adjusting Hspace instead of anchoring center and it looses its alignment.

the Vspace works ok

1 Like

This is interesting. I haven’t checked but I believe this has always worked this way but not clear if this is the intended behavior.

Sounds like you’re expecting X Alignment to dynamically adjust for HSpace adjustments which seems intuitive to me.

Here’s a sample of the result of each X Alignment.

I suspect this is more about how HSpace is implemented. The additional space is directly added behind each character. So there is actually physical space at the end of each character that’s padding and directly impacting the spacing. It doesn’t affect Left alignment since there is no space to the left of each character. However, it affects middle and right alignment. You can see this if you take a look a the cursor location relative to the letter position.

image

@Rick here for comment.

1 Like

I’ve revisited this based on another post:

I can confirm that this does appear to be a regression from 1.4.05 or at least a change in behavior.

@Rick @LightBurn for awareness.

Will take a closer look, thank you. :slight_smile:

Update: We’ve have a fix for the issue with text not using the proper alignment when HSpace is non-zero. Fix will be in 1.6, at a minimum.

Im also struggling with this. Lightburn is now applying Hspace only from left. Center and right aligned text is subsequently broken

And what if my subscription expires before 1.6 is released? It’s a bug in 1.5 which I own. Does this mean you can fix this but I could potentially not get a fix without renewing?

That’s correct - you can always roll back to a prior version that doesn’t exhibit this bug. Releases · LightBurnSoftware/deployment · GitHub

We have to draw a line in the sand somewhere. If the issue is a small bug patched in a X.X.## release then usually we’ll backdate it a little bit. But major releases do get date advances that are checked by LightBurn when updating.

Ouch, putting bugfixes for old versions in a major update. I guess that’s how things work.

We follow semantic versioning, which means bugfixes (patches) that don’t add features are Patch releases. More details here: https://semver.org/

Sometimes, when we have a bugfix that’s close to a Minor release, we’ll roll it into the Minor release rather than issue a Patch shortly before a Minor release.

@pnevma and @berainlb

If willing, we have a patch release coming you can access, currently in our beta folder.

  • Bugfix: HSpace wasn’t being included in new font advance code

Thank you. Saw that. Will give it a try in a bit.

I guess the real question is what is this “font advance code”? First I’ve heard mention of it.

I haven’t tested extensively but the 1.5.02 public beta seems to correct this as advertised, at least in this contrived example.

It was determined that the code we were using to ask for the width of a string of text was lying. It was giving us “where would you start drawing the next character”, not “what is the total width of this string”.

1 Like