Strange update/loading issue with installed font

[Phillipus]

Windows 10

1. I copied a font (Ambrosia Demo) into the "Archi4/fonts" folder.
2. I set one Business Actor in a View to this font.
3. Keep the View open
4. Close Archi
5. Open Archi
6. The font does not show until I click on the Business Actor or resize the View window or do some action that causes a refresh/repaint

[jbsarrodie]

That's for reporting. I'll check when I'll boot my Windows laptop later tonight.

[Phillipus]

It's worse on Mac.

Let's say you have an object set to "MyFont 14"

If the View is already open when Archi starts, this font does not display at all, even if you create new objects and set it to that font. Then, the only way to get it working is to set the font of the object to "MyFont 12" or "MyFont 10". But the original font and size ("MyFont 14") will never display again. It's as if the font and size is not being loaded.

But if the View is not open at startup it's OK.

My theory is that user fonts have to be loaded before GEF renders any figures. And if the View is already open at launch this isn't the case. Because this is a plug-in, it will load after main Archi code.

[Phillipus]

I tried moving the Font Loader code into ArchiPlugin and this fixes the issue.

It seems that there is no guarantee of the order of loading plug-ins (see https://stackoverflow.com/questions/407752/guaranteed-eclipse-plugin-startup-order) and in this particular case, the fonts have to be loaded before GEF/Draw2D draws things.

[Phillipus]

So far, the only way I can see to resolve this issue is to not distribute this as a plug-in, but to put the font loading code in the main ArchiPlugin class.

[Phillipus]

I've figured out a way to force plug-ins to start up early.

ArchiPlugin can iterate through all registered plug-ins that implement the org.eclipse.ui.startup extension and instantiate their startup class if the extension has an id with something like "earlyStart". So far this works on Mac (which is the worst case).

[Phillipus]

So far this works on Mac (which is the worst case).

And on Windows.

I can create a new extension point in Archi that will load plug-ins early (unlike org.eclipse.ui.startup which is not guaranteed). This would be generic and we could even have a priority field.

[jbsarrodie]

I can create a new extension point in Archi that will load plug-ins early

Than you for the investigation. That seems a good option.

What I don't understand is that I didn't notice any issue on Windows (I simply didn't test SVG/PDF).

[Phillipus]

I simply didn't test SVG/PDF

This issue is due to startup not loading a font and not being used in a View. Try the steps to reproduce, above.

[Phillipus]

Try the steps above. In all my tests on Windows and Mac, if the View is open when loading Archi, the font is not loaded (except on Windows if you click or move something)

I've committed some changes in an early-start branch for Archi and an early-start branch for this plug-in. You need both for it to work.

Archi, when starting now looks for plug-ins that implement the org.eclipse.ui.startup extension. If the declaring extension point has an id of "earlyStart" (in plug-in.xml) it is instantiated. This causes the plug-in to load even earlier.

This is a bit of a hack and is only really needed for this one plug-in. There's no guarantee it will work under all circumstances.

The alternative is to put the font loading code into main Archi code.

[jbsarrodie]

Ok, I did test on my current laptop which runs Linux and this works! The SVG export also works even with ligatures (wich never worked before).

So it seems the initial issues with Linux were related to this one.

If it now works on all OS, then it might be better to add it to main Archi code (we'll need it in the future anyway to use some custom icons).

[Phillipus]

Did you see the loading/refresh issue on Windows before this patch?

[jbsarrodie]

Wait a minute, I have something strange on my Linux laptop...

[Phillipus]

I don't think it will fix the Linux issue. Because when we ran it as POC it was not in a plugin.

We weren't loading in the right place.

[jbsarrodie]

Wait a minute, I have something strange on my Linux laptop...

I messed up with my fonts. So this does fix the font loading issue on Linux, but this doesn't fix the SVG export (fonts are not embedded).

[Phillipus]

Fuck yes it does!

The SVG issue is completely different (AWT, Batik, etc)