Fix namespace hardcode

[0zd0]

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

[bsweeney]

Seems reasonable.

[bsweeney]

Does strauss automatically handle namespace references in use statements? What about the strings containing \FontLib\Table\... references around line 400 in this file?

[bsweeney]

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

[0zd0]

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

[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.

[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.

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

[bsweeney]

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.

[BrianHenryIE]

(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.