Vertical text alignment issues in r241 with enabled BBCode

[dop2000]

Problem description

There is a big difference with text vertical alignment between r234 and 241. This seems to be happening with some web fonts and when BBCode is enabled.

Attach a .c3p

https://www.dropbox.com/s/ng2hiqszddsywcy/TextVerticalAlign.c3p?dl=0

Observed result

More details

Affected browsers/platforms: Chrome, Desktop App and iOS export.

It doesn't happen in Firefox - the text is slightly below the red line there.

First affected release: r241

System details

View details

Platform information Browser: Chrome Browser version: 89.0.4389.114 Browser engine: Chromium Browser architecture: 64-bit Context: browser Operating system: Windows Operating system version: 10 Operating system architecture: 64-bit Device type: desktop Device pixel ratio: 1.25 Logical CPU cores: 4 Approx. device memory: 8 GB User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36 C3 release: r241 (stable) Language setting: en-US Local storage Storage quota (approx): 127 gb Storage usage (approx): 324 mb (0.2%) Persistant storage: Yes Browser support notes This list contains missing features that are not required, but could improve performance or user experience if supported. Nothing is missing. Everything is OK! WebGL information Version string: WebGL 2.0 (OpenGL ES 3.0 Chromium) Numeric version: 2 Supports NPOT textures: yes Supports GPU profiling: yes Supports highp precision: yes Vendor: Google Inc. Renderer: ANGLE (Intel(R) HD Graphics 620 Direct3D11 vs_5_0 ps_5_0) Major performance caveat: no Maximum texture size: 16384 Point size range: 1 to 1024 Extensions: EXT_color_buffer_float EXT_color_buffer_half_float EXT_disjoint_timer_query_webgl2 EXT_float_blend EXT_texture_compression_bptc EXT_texture_compression_rgtc EXT_texture_filter_anisotropic EXT_texture_norm16 KHR_parallel_shader_compile OES_draw_buffers_indexed OES_texture_float_linear WEBGL_compressed_texture_s3tc WEBGL_compressed_texture_s3tc_srgb WEBGL_debug_renderer_info WEBGL_debug_shaders WEBGL_draw_instanced_base_vertex_base_instance WEBGL_lose_context WEBGL_multi_draw WEBGL_multi_draw_instanced_base_vertex_base_instance WEBGL_video_texture WEBGL_webcodecs_video_frame OVR_multiview2 Audio information System sample rate: 48000 Hz Output channels: 2 Output interpretation: speakers Supported decode formats: WebM Opus (audio/webm; codecs=opus) Ogg Opus (audio/ogg; codecs=opus) WebM Vorbis (audio/webm; codecs=vorbis) Ogg Vorbis (audio/ogg; codecs=vorbis) MPEG-4 AAC (audio/mp4; codecs=mp4a.40.5) MP3 (audio/mpeg) FLAC (audio/flac) PCM WAV (audio/wav; codecs=1) Supported encode formats: WebM Opus (audio/webm; codecs=opus) Video information Supported decode formats: WebM AV1 (video/webm; codecs=av01.0.00M.08) MP4 AV1 (video/mp4; codecs=av01.0.00M.08) WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8) Ogg Theora (video/ogg; codecs=theora) H.264 (video/mp4; codecs=avc1.42E01E) Supported encode formats: WebM VP9 (video/webm; codecs=vp9) WebM VP8 (video/webm; codecs=vp8)

[AshleyScirra]

This is really tricky. It's a continuation of #2985. The metrics calculations involved are proving hard to get right.

There's an improvement in r243.2 but I'm going to look in to this a little further to see if I can get it exactly right - these changes cause lots of projects to have to tweak their text positions, and I really want to make sure we only make everyone have to do those changes once more if necessary...

[Boulerzzz]

We redid everything for r241 (because that one was supposed to be the correct one) and now after r243.2 all that was for nothing and next stable we have to rebuild everything again.

An improvement does not matter. Unless it is perfect there still needs to be adjustments made so big deal if it is 5px or even 500px off, just leave it like the last stable r241. Or make an option to use r241 metrics or another metric.

Regards Jim Rosendal

From: Ashley @.> Sent: Wednesday, 7 April 2021 18.30 To: @.> Cc: @.>; @.> Subject: Re: [Scirra/Construct-3-bugs] Vertical text alignment issues in r241 with enabled BBCode (#4711)

This is really tricky. It's a continuation of #2985https://github.com/Scirra/Construct-3-bugs/issues/2985. The metrics calculations involved are proving hard to get right.

There's an improvement in r243.2 but I'm going to look in to this a little further to see if I can get it exactly right - these changes cause lots of projects to have to tweak their text positions, and I really want to make sure we only make everyone have to do those changes once more if necessary...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Scirra/Construct-3-bugs/issues/4711#issuecomment-815009607, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIJIHOLME3DNFJVUDGJ3ZATTHR3C5ANCNFSM42O4VPCA.

[AshleyScirra]

I apologise for the inconvenience, but if the calculation is not correct, then we have to fix it. The only other alternative is to leave it broken forever. I know this means making changes to projects and I am always reluctant to make breaking changes, but I think this is something we have to get right for the long term, otherwise centered text will never work correctly, which is worse than some short-term inconvenience.

[Boulerzzz]

I see. I will just have to avoid future releases as long as possible until I have time to redo it once again.

From: Ashley @.> Sent: Wednesday, 7 April 2021 18.49 To: @.> Cc: @.>; @.> Subject: Re: [Scirra/Construct-3-bugs] Vertical text alignment issues in r241 with enabled BBCode (#4711)

I apologise for the inconvenience, but if the calculation is not correct, then we have to fix it. The only other alternative is to leave it broken forever. I know this means making changes to projects and I am always reluctant to make breaking changes, but I think this is something we have to get right for the long term, otherwise centered text will never work correctly, which is worse than some short-term inconvenience.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/Scirra/Construct-3-bugs/issues/4711#issuecomment-815022887, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIJIHOM6RCEODHCGETI3LSTTHR5H5ANCNFSM42O4VPCA.

[AshleyScirra]

I've worked on this some more and I think I've got it as good as it can get - it also looks to match exactly to the alignment done when BBcode is disabled, which I think is a good sign the new calculation is correct. I've marked this issue to check next release so others affected can check their projects and verify how it looks, since the alignment seems to depend on the specific font in use. Hopefully this is the last time we have to change this - I know the changes are painful, but if we can get it right, it should never have to be adjusted again.

[AshleyScirra]

r244 is now released and has (another) updated vertical alignment calculation. I'm fairly confident this one is now correct, as it appears to be exactly the same as the vertical alignment when disabling BBcode (i.e. when using the legacy "top" baseline mode). It would be good to get verification from anyone affected though that text vertical center alignment is now working as expected with your projects in r244+.

[Dramamini]

Almost there! It appears to be exactly the same when disabling BBcode and this is a good sign, but in latest beta (r244) when I increase text object's height, text is slightly up again. Here are my results comparing r243.2 and r244:

[Dramamini]

This is the c3p file: TextAlignment.zip

[AshleyScirra]

I think the vertical alignment calculation was including some unnecessary padding that slightly shifted the text upwards. I've adjusted it for the next beta again, which makes all the text in that project file all appear aligned the same on the white line. Let's see how it looks in the next beta again, hopefully we're nearly there...

[AshleyScirra]

OK, I think this should all be working correctly now in r245. Can those affected confirm vertical alignment is working as expected in that release?

[Boulerzzz]

I made several tests with different fonts and sizes. It looks to be correct on my end now. I tested the center alignment.

edit1: Top alignment changes y position if you enable/disable bbcode.

edit2: Center alignment with bbcode enabled displays completely wrong y position on emulator in android studio. On physical device is seems to be correct though.

edit3: On iOS the text alignment is shifted downward.

So center works good on Android but iOS shift the text y position downward. Top alignment changes when you enable/disable bbcode. Also the android studio emulator shift all text downward. But then after build it seems to be correct again. Any idea why that could be?

Thanks

[dop2000]

I haven't tested on mobile, but in preview the fonts I'm using are aligned better now. Thanks!

[sotano42]

r245 is still rendering wrong, the vertical centered alignment is close to being correct, now it produces the same result when using bbcode enabled. Top and bottom vertical alignment are still rendering incorrectly, any font produces the same result.

BBCode Enabled

BBCode Disabled

[AshleyScirra]

@sotano42 - I can't see anything wrong in your screenshots. The center vertical alignment looks correct (consider how far the 'g' hangs down, which means the height of the line extends further down than the word "Text" at the start of the line). The top alignment is slightly different with BBcode enabled by design (when disabled, it is too close to the top and some tall characters may have the top cut off; for backwards compatibility we only changed this when BBcode is enabled). When BBcode is enabled the bottom alignment is based on the fontBoundingBoxDescent measurement of the font in order to prevent any text being cut off at the bottom; looking at how far the 'g' descender goes, it's possible the font has other characters which descend down further and so could be cut off unless it takes in to account this space (when BBcode is disabled it ignores this measurement and so could again result in characters being cut off at the bottom).

This is pretty complicated, mostly for backwards-compatibility reasons, but I think it's all working as designed now. The original filed issue only covered center vertical alignment, which I believe is now working correctly. I don't see any evidence of a problem with other text alignments (note that as described, top and bottom alignment may be different with BBcode on/off, by design). So closing this issue - if you think there are any remaining text alignment issues, please file a new issue following the guidelines.

[sotano42]

@sotano42 - I can't see anything wrong in your screenshots. The center vertical alignment looks correct (consider how far the 'g' hangs down, which means the height of the line extends further down than the word "Text" at the start of the line). The top alignment is slightly different with BBcode enabled by design (when disabled, it is too close to the top and some tall characters may have the top cut off; for backwards compatibility we only changed this when BBcode is enabled). When BBcode is enabled the bottom alignment is based on the fontBoundingBoxDescent measurement of the font in order to prevent any text being cut off at the bottom; looking at how far the 'g' descender goes, it's possible the font has other characters which descend down further and so could be cut off unless it takes in to account this space (when BBcode is disabled it ignores this measurement and so could again result in characters being cut off at the bottom).

This is pretty complicated, mostly for backwards-compatibility reasons, but I think it's all working as designed now. The original filed issue only covered center vertical alignment, which I believe is now working correctly. I don't see any evidence of a problem with other text alignments (note that as described, top and bottom alignment may be different with BBcode on/off, by design). So closing this issue - if you think there are any remaining text alignment issues, please file a new issue following the guidelines.

Ok, for the vertical I didn't consider the bottom, so I guess it's right.

For the top and bottom, it looks weird but if it works like that by design it's new for me. Thanks for clarifying.