[Bug]: Avatar New style looks weird

[AndyXheli]

⚠️ This issue respects the following points: ⚠️

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

Bug description

Steps to reproduce

After this was implemented #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?

• Default user-backend (database)
• 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! 🙏
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?

[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 NC 27

[AndyXheli]

Still an issue on NC 27.0.1 tried below and cleared cache still an issue

# 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

[danxuliu]

The problem is in ImageMagick itself; before ImageMagick 6.9.10-36 (specifically, ImageMagick/ImageMagick6@3b6ba12), if the internal renderer is used (that is, if ImageMagick is built with --without-rsvg and Inkscape is not in $PATH), the SVG used for avatars in Nextcloud is not properly rendered.

To check this, first save the SVG of a Nextcloud avatar in a test.svg file:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="64" height="64" version="1.1" viewBox="0 0 500 500" xmlns="http://www.w3.org/2000/svg">
	<rect width="100%" height="100%" fill="#e8f1f8"></rect>
	<text x="50%" y="350" style="font-weight:normal;font-size:280px;font-family:'Noto Sans';text-anchor:middle;fill:#1e78c1">U</text>
</svg>

Then, build ImageMagick 6.9.10-35 and 6.9.10-36 and check the generated PNG file (note that you will need to replace {PATH-TO-THE-DIRECTORY-OF-THE-TEST-SVG-FILE} with the proper value):

docker run --detach --interactive --tty --volume {PATH-TO-THE-DIRECTORY-OF-THE-TEST-SVG-FILE}:/tmp/imagemagick-test --name imagemagick-test ubuntu:20.04 bash
docker exec imagemagick-test bash -c "apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install --assume-yes build-essential git autoconf pkg-config libxml2-dev libfreetype6-dev libfontconfig1-dev gsfonts"
docker exec imagemagick-test bash -c "useradd --create-home imagemagick"
docker exec --user imagemagick --workdir /home/imagemagick imagemagick-test bash -c "git clone https://github.com/ImageMagick/ImageMagick6"
docker exec --user imagemagick --workdir /home/imagemagick/ImageMagick6 imagemagick-test bash -c "git checkout 6.9.10-35"
docker exec --user imagemagick --workdir /home/imagemagick/ImageMagick6 imagemagick-test bash -c "mkdir build && cd build/ && ../configure --without-rsvg && make && MAGICK_CONFIGURE_PATH=/home/imagemagick/ImageMagick6/config:/home/imagemagick/ImageMagick6/build/config ./utilities/convert /tmp/imagemagick-test/test.svg /tmp/imagemagick-test/test-6.9.10-35.png && cd .."
docker exec --user imagemagick --workdir /home/imagemagick/ImageMagick6 imagemagick-test bash -c "git checkout . && git checkout 6.9.10-36"
docker exec --user imagemagick --workdir /home/imagemagick/ImageMagick6 imagemagick-test bash -c "cd build/ && ../configure --without-rsvg && make && MAGICK_CONFIGURE_PATH=/home/imagemagick/ImageMagick6/config:/home/imagemagick/ImageMagick6/build/config ./utilities/convert /tmp/imagemagick-test/test.svg /tmp/imagemagick-test/test-6.9.10-36.png && cd .."

To solve the issue you need to update ImageMagick to, at least, ImageMagick 6.9.10-36. If you are using Ubuntu 20.04 you can upgrade to Ubuntu 22.04, which uses ImageMagick 6.9.11-60 and therefore no longer has this issue.

ImageMagick renders SVG files using either its internal render, rsvg-convert or Inkscape, so if you are in an old ImageMagick version and you can not update it you might be able to work around the issue just installing Inkscape.

You could also rebuild ImageMagick with RSVG support, so it renders the SVG files through rsvg-convert rather than its internal renderer. However it seems that rsvg-convert has its own issues and it is not currently used when generating the avatars.

Alternatively, if your distributon provides SVG support for ImageMagick in an additional package (for example, libmagickcore-6.q16-6-extra in Ubuntu 20.04), you can also remove that package to remove support for SVG from ImageMagick; GD will be used instead of ImageMagick to generate the avatars and they will look as expected. The drawback is, however, that you may lose some other feature that depend on SVG support in ImageMagick, like theming icons.

Finally, note that the rendering was wrong too with the old avatar style, but since Nextcloud 16 the problem was not visible because the font could not be found (the path to the font was not updated when lib/private/Avatar.php was moved to lib/private/Avatar/Avatar.php) and thus it always ended being rendered with GD; with the new avatar style the path got fixed and thus the problem appeared.