[Bug]: Avatar New style looks weird

[AndyXheli]

⚠️ This issue respects the following points: ⚠️

• [X] This is a bug, not a question or a configuration/webserver/proxy issue.
• [X] This issue is not already reported on Github (I've searched it).
• [X] Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• [X] Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• [X] I agree to follow Nextcloud's Code of Conduct.

Bug description

Steps to reproduce

After this was implemented https://github.com/nextcloud/server/pull/33752

Expected behavior

Should look more clear. Th users back end is running LDAP @CarlSchwan what do you think?

Installation method

No response

Operating system

No response

PHP engine version

No response

Web server

No response

Database engine version

No response

Is this bug present after an update or on a fresh install?

No response

Are you using the Nextcloud Server Encryption module?

No response

What user-backends are you using?

• [x] Default user-backend (database)
• [x] LDAP/ Active Directory
• [ ] SSO - SAML
• [ ] Other

Configuration report

No response

List of activated Apps

Na

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[AndyXheli]

Not fixed in NC 25 Beta 7

Same results

[CarlSchwan]

Oh now I see the issue, it wasn't about dark theme but the weird border

[AndyXheli]

Let me know if you have a manual patch you'd like to me test out

[AndyXheli]

Hello still having this issue on NC 25 RC1

[szaimen]

@CarlSchwan could this happen if imagick is not enabled on an instance?

[AndyXheli]

Just to confirm I do have imagick installed

[skjnldsv]

@andyxheli does your imagick setup have svg enabled? What is your instance overview saying?

https://cloud.domain.com/settings/admin/overview

[AndyXheli]

Hi @skjnldsv yes I have php-imagick & imagemagick installed. In the server overview I got a green check no issues or recommendations

At first I didn't have imagemagick I just had php-imagick but I didn't get any warning on the server so I did some research and I seen that imagemagick so I did that also rebooted the server still the same issue

[Ho551]

Same problem on NC 25.0.1

[skjnldsv]

@Ho551 have you upgrade through beta or RC before reaching stable 25 ?

If so, can you clear your avatars and try generate them again?

# cd into your appdata avatar directory
cd data/appdata_xxxxx/avatar

# look for generated avatar and delete their containing directory
find -name 'generated' -type f -execdir pwd \; | xargs -d '\n' rm -rfv

# update file cache to make Nextcloud generate them again on demand
occ files:scan-app-data avatar

[Ho551]

Thanks for the hint! I've updated through beta channel. I wanted to test NC in my test system first. I tried to generate the avatars again. Now the avatar in top bar looks good (for one user), but in setttings and talk it looks still weird:

[skjnldsv]

I'm guessing this is a browser cache issue. Please clear cache or try in a private window @Ho551 ?

[Ho551]

That's what I suspected too, but the problem still persists. It occurs on Chrome, Safari and Firefox browsers. Is there any way I can help further @skjnldsv?

[skjnldsv]

Thanks, it means the problem persist indeed :) I'll think about how to tackle that

[MoritzDPTV]

Hey there,

I'm having some similar issues. It seems to be related with the User Status app. After disabling it, the not-so-beautiful avatars appeared. Re-enabling the app only changed my personal avatar in the top right corner (which returns to be not-so-beautiful when (re)loading the page, but is replaced after the page is fully loaded with the better avatar.)

Nextcloud Version: 25.0.1 Firefox Version: 106.0.2 (64-bit) Client Ubuntu Version: 22.04.1 LTS

[skjnldsv]

Could be an outdated component, indeed. Nonetheless that does not explains this

For everyone that have this issue, can you manually fetch the avatar files of the broken users in your data/appdata/avatar/USERID and post them here please?

I need to know the source of the issue, if it's coming from a broken generation or somewhere else :)

[Ho551]

@skjnldsv Looking at the generated images, this seems to be the problem. In the 64x64px image, the unsightly edge is already visible

I attach the entire generated avatars in a zip archive avatar.zip

[skjnldsv]

Thank you @Ho551 , it really helps! :pray: Ok, so it is definitely something with our svg or the php dependency

[Ho551]

You're welcome! I have probably found the problem. My server was set up with PHP 8.0 until 2 days ago. Now I've updated to PHP 8.1 and just regenerated the avatars again...Now everything looks fine:

So just update everyone to PHP 8.1 - it's better either way 😁

[skjnldsv]

@come-nc ring a bell? Maybe a difference in parameters between 8.0 and 8.1?

[AndyXheli]

I'm running PHP 8.1 on NC25.0.1 and still have issue

[come-nc]

@come-nc ring a bell? Maybe a difference in parameters between 8.0 and 8.1?

Hum, kind of. I remember having a problem with gd or imagick changing result is some PHP version.

[come-nc]

I have this test script left over on my disk, which indicates I did have trouble with this:

<?php

$font = '/usr/share/fonts/truetype/noto/NotoSans-Regular.ttf';

var_dump(imagettfbbox(12, 0, $font, 'E'));

But I’m failing to find any more information on this. All I can see is I have commands in my history to check which version of gd/freetype is linked to my PHP build. So I can only advise to test the result of imagettfbbox and compare it accross PHP versions and setups.

[come-nc]

Here is what I have locally:

> php ~/dev/test-freetype.php
array(8) {
  [0]=>
  int(1)
  [1]=>
  int(0)
  [2]=>
  int(8)
  [3]=>
  int(0)
  [4]=>
  int(8)
  [5]=>
  int(-11)
  [6]=>
  int(1)
  [7]=>
  int(-11)
}
> php --info|grep -i gd
/etc/php/8.1/cli/conf.d/20-gd.ini,
gd
GD Support => enabled
GD headers Version => 2.3.0
GD library Version => 2.3.0
gd.jpeg_ignore_warning => 1 => 1
> php --info|grep -i freetype
FreeType Support => enabled
FreeType Linkage => with freetype

And with my PHP 8.2 built from source for tests:

> ~/dev/php-src-git/sapi/cli/php ~/dev/test-freetype.php
array(8) {
  [0]=>
  int(1)
  [1]=>
  int(0)
  [2]=>
  int(8)
  [3]=>
  int(0)
  [4]=>
  int(8)
  [5]=>
  int(-12)
  [6]=>
  int(1)
  [7]=>
  int(-12)
}
> ~/dev/php-src-git/sapi/cli/php --info|grep -i gd
Configure Command =>  './configure'  '--with-ldap' '--with-ldap-sasl' '--with-zip' '--with-curl' '--with-openssl' '--with-zlib' '--enable-mbstring' '--enable-pcntl' '--enable-intl' '--with-password-argon2' '--with-freetype' '--with-jpeg' '--enable-gd' '--with-imagick' '--enable-exif'
gd
GD Support => enabled
GD Version => bundled (2.1.0 compatible)
gd.jpeg_ignore_warning => On => On
> ~/dev/php-src-git/sapi/cli/php --info|grep -i freetype
Configure Command =>  './configure'  '--with-ldap' '--with-ldap-sasl' '--with-zip' '--with-curl' '--with-openssl' '--with-zlib' '--enable-mbstring' '--enable-pcntl' '--enable-intl' '--with-password-argon2' '--with-freetype' '--with-jpeg' '--enable-gd' '--with-imagick' '--enable-exif'
FreeType Support => enabled
FreeType Linkage => with freetype
FreeType Version => 2.11.1

So there is a 1 pixel difference between my 2 local versions already.

[szaimen]

Interesting! So is the issue maybe only reproducible on php 8.0 and below?

[come-nc]

No I think it depends upon which gd and/or freetype version is used. We need to test on as many setups as possible to see common patterns.

[AndyXheli]

Still an issue on NC 25.0.3

[schiessle]

In case some of the devs need a instance to reproduce it. The problem also exists on the LTD's on try.nextcloud.com

[AndyXheli]

Still an issue on NC 26.0.0

[AndyXheli]

Still an issue NC 27