php-font-lib icon indicating copy to clipboard operation
php-font-lib copied to clipboard

Fix namespace hardcode

Open 0zd0 opened this issue 6 months ago • 6 comments

When we prefix namespaces with https://github.com/BrianHenryIE/strauss problems arise

0zd0 avatar Jun 27 '25 18:06 0zd0

If the issue is around construction of a namespace in a string, you might also look at the Dompdf project.

bsweeney avatar Jun 28 '25 22:06 bsweeney

If the issue is around construction of a namespace in a string, you might also look at the Dompdf project).

this is exactly related to dompdf. with this fix everything started working for us and it seems like there are no errors yet

0zd0 avatar Jun 29 '25 14:06 0zd0

I'm curious why only these lines prove problematic. There is similar logic in elsewhere in FontLib as well as in Dompdf that builds a string containing a class reference. I would expect similar issues there. I suppose it's possible you're not hitting those in this library and that only FontLib is impacted because another dependency in your project is using the "FontLib" namespace.

bsweeney avatar Jun 29 '25 19:06 bsweeney

I'm curious why only these lines prove problematic. There is similar logic in elsewhere in FontLib as well as in Dompdf that builds a string containing a class reference. I would expect similar issues there. I suppose it's possible you're not hitting those in this library and that only FontLib is impacted because another dependency in your project is using the "FontLib" namespace.

Maybe. There are no more moments like this in this library?

0zd0 avatar Jun 29 '25 19:06 0zd0

Maybe. There are no more moments like this in this library?

In the file you modified there's this block:

if (!self::$raw) {
  $name_canon = preg_replace("/[^a-z0-9]/", "", strtolower($tag));

  $class = "FontLib\\Table\\Type\\$name_canon";

  if (!isset($this->directory[$tag]) || !@class_exists($class)) {
    return;
  }
}
else {
  $class = "FontLib\\Table\\Table";
}

and in Dompdf there's a few, like this one:

$decorator  = "Dompdf\\FrameDecorator\\$decorator";
$reflower   = "Dompdf\\FrameReflower\\$reflower";

I'm fine to accept the change you made and wait to resolve others when they crop up. I'm not familiar with the tool you're using so I don't know what best practice would be to prevent potential rename misses. And I'm not planning to spend a lot of time researching it since it's not a primary usage scenario.

bsweeney avatar Jun 29 '25 20:06 bsweeney

(I maintain Strauss). It's really just a fancy find+replace for namespaces, classes etc. So, e.g. Dompdf can be used in multiple WordPress plugins without worrying about a different plugin's files being autoloaded but using a different version of the library

It scans all the files, finds all the namespaces, then uses a big regex to substitute the change.

In your example, changing Dompdf\\ -> Strauss\\Test\\Dompdf\\ works with:

$decorator  = "Dompdf\\FrameDecorator\\$decorator";

but not with:

$decorator  = "Dompdf\\$decorator";

so that explains why this PR was needed for the two cases it changes.

TBH, I'm surprised it worked at all. But I've a regression test written now so we can rest knowing it will continue to work.

There is an issue open about partial matches + strings and I'll look at this again when I'm tackling that.

BrianHenryIE avatar Jul 01 '25 20:07 BrianHenryIE