Java.awt and itext.FontFactory font refactoring: What's the best way to refactor a large code base to a new font?

1 day ago 3
ARTICLE AD BOX

I am working with a large legacy application. Throughout the application, there are calls to generate PDFs with iText, or to generate text headers for charts etc. which utilize java.awt.Font to load the proper font.

Previously this was always run on Windows servers, but now we're putting the application on Linux servers, and ideally it would look the same regardless of the operating system.

I've selected a series of replacement fonts that we can use on both operating systems, but I'm a bit stumped on the best way to implement this "refactoring".

For iText, I'm fine just manually updating them by hand, since there are fewer places it's used. Unfortunately the java.awt.Font issue is messier to resolve because it's all over the place.

My plan originally, was that I was hoping I could add the fonts to the java.awt at runtime (which I have done successfully already), and then reassociate the old font family names to the new fonts.

Basically, when my application code says new Font("Arial", Font.Bold, 18pt); I'd like it to render as if it said, new Font("Arimo", Font.Bold, 18pt); . When I manually update those locations like that, it does render with the new font, but again, manually updating all of those locations throughout the code, or even tool assisted with AI would be kind of a nightmare to do/human review.

Can anyone help give me guidance on a better methods? I'm open to looking into doing java font config file editing if it's a good way to go, but from what research I have done it looks like it's not advisable for an application like this.

If there's any useful information I've left out (there always is), I'm happy to provide additional detail. Thank you in advance!

Read Entire Article