I'm going to review this code in the coming days, maybe it will be slightly modified. I really appreciate your feedback.

I'm working on a new more cleaner implementation. Will return when it will be done.

@garak I've reworked this PR. All the logic of parsing SVG fonts and unicode characters (code points) extracted to separated unit tested packages:

• https://github.com/cybercog/php-svg-font
• https://github.com/cybercog/php-unicode

If you are OK with such solution I will continue to work towards this implementation.

Motivation behind this change: reading and parsing SVG fonts and unicode strings not that easy as it might look like. For example current solution does not allow us to use composition characters like composable emojis. We may add support later in separate package and do not change this package code, because solution may be very complicated.

Things to do before merge:

• Cover with high level tests
• Tweak API of reading fonts
• Make calculator results same as GD one (if possible)
• Make stable releases of dependencies

I have one question about GD calculator. There is a code:

public function calculateWidth(string $text, int $size = self::TEXT_SIZE): float
{
    $size = $this->convertToPt($size);
    $box  = \imagettfbbox($size, 0, $this->fontPath, $text);

    return \round(\abs($box[2] - $box[0]) + self::SHIELD_PADDING_EXTERNAL + self::SHIELD_PADDING_INTERNAL, 1);
}

private function convertToPt(int $pixels): float
{
    return \round($pixels * 0.75, 1);
}

Why do we decreasing font size using round($pixels * 0.75, 1)?

Update: I suppose I found an answer. GD1 used pixels as first argument, GD2 uses points.

Tests are failing on code style. Same as in #101. It looks like CS Fixer issue, need fix it and re-run here.

The code is OK for me, but it needs to be tested

@garak I wrote tests for the new SvgTextCalculator and for GdTextCalculator (they were missing).

Tests are failing on code style. Same as in #101. It looks like CS Fixer issue, need fix it and re-run here.

I guess you can easily fix them. If you want to save time, my advice is to run php-cs-fixer on your local environment before pushing your commit.

On a second thought, probably it's useless to have the CS checked inside versions. Please remove that part, let's keep only the initial global CS check

@garak what part are you talking about? CS fails on infrastructure code, not committed one.

This part https://github.com/badges/poser/blob/master/.github/workflows/php.yml#L45

I'm fixing it here: #102

Please rebase! ;)

I'm fixing it here: #102

but you fixed the symptom, not the problem itself :-(

@garak @JellyBellyDev rebased, ready for review

I'm fixing it here: #102

but you fixed the symptom, not the problem itself :-(

it is good as temporary solution, but later could be changed as well

@garak @JellyBellyDev who can make minor release?

Done! 😉

@JellyBellyDev release does not appeared in Packagist: https://packagist.org/packages/badges/poser

Now yes! 👍🏻

I always forget that I don't have the privileges to set the package self-update hook on packagist and with each release I have to update it manually