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)

[Phillipus]

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

I would prefer this than relying on an early startup hack which might or might not work under different conditions.

[Phillipus]

New branch in Archi code - font-loader Try that one. Don't forget to remove the Font Loader plug-in from your launch config!

[Phillipus]

Tested on Windows, Mac and Linux. Works in all cases.

@jbsarrodie Does this now fulfil the original use case? Perhaps also we could add a preference for the user fonts folder?

[jbsarrodie]

Does this now fulfil the original use case?

I think so. But the question is which fonts do we ship with Archi. My reference set of fonts is:

• Roboto & Roboto Condensed because they look good and don't take much space. (I would even suggest to make them the default for elements and relationships but we have to wait until we fix the SVG/PDF issue)
• FontAwesome so that people can add icons to their views when needed
• Numberpile for numbering elements or relationships

But of course that a bit an arbitrary choice based on my experience.

In all cases, we have to make sur this plugin is exported as a folder and not a single jar. This will make it easier to change the set of fonts if someone creates its own Archi package.

Perhaps also we could add a preference for the user fonts folder?

I'd say yes because we do it for other things like JasperReports, scripts....

[Phillipus]

I have mixed feelings about shipping fonts with Archi. It might seem to be a bit opinionated (i.e not everyone might agree)?

In all cases, we have to make sur this plugin is exported as a folder and not a single jar. T

If fonts are shipped with Archi they would be in a "fonts" folder in the com.archimatetool.editor_X.X.X.XXXXXXXX plug-in which is a folder.

[Phillipus]

but we have to wait until we fix the SVG/PDF issue

I don't think it's fixable on Linux or Windows. See archimatetool/archi#628 (comment)

[Phillipus]

Well, that was some weird stuff...

I had it all working and was loading the fonts from the ArchiPlugin#start() method by calling Display#getDefault()

But then on Mac I noticed that when launching Archi from Eclipse the app was called "SWT" not "Archi". More detective work showed that I should not be calling Display#getDefault() at that point. So I've moved the font loading code into ArchiWorkbenchWindowAdvisor and it is working OK on all three platforms. There's also a preference for user's font folder in Fonts Preferences.

[jbsarrodie]

I have mixed feelings about shipping fonts with Archi. Seems a bit opinionated?

Of course that's opinionated. But I'm always right ;-)

More seriously, we can simply make sure the plugin's fonts folder exist and is loaded if someone create a packaged version of Archi (that's what I'll do to make sure everyone in my team has the same set of fonts).

I don't think it's fixable on Linux or Windows.

I know how to fix it and just did a successful POC ;-)

In fact, instead of converting the font to an SVG font, we "simply" have to declare a font like we'd do with CSS and use the base64 encoded version of the font file. So the generated file should look like the one attached (only Numberpile is embedded for the sake of the example).

Default View.svg.txt

Of course, this involves:

• getting the list of all fonts used in the view to be exported
• finding each font file (can we do this only based on the loaded font?)
• encode each font to base64
• generate the font-face sections and add them to the SVG

[Phillipus]

Sounds complicated. Don't forget embedded fonts works on Mac. It really is an AWT/Batik issue.

[Phillipus]

@jbsarrodie Shall we go with the font loading code in main Archi now? If so, maybe we should think about archiving this plug-in?

[jbsarrodie]

@jbsarrodie Shall we go with the font loading code in main Archi now? If so, maybe we should think about archiving this plug-in?

Yes and yes ;-)

[Phillipus]

Yes and yes ;-)

Suggest removing the release files and putting this in archive mode? If OK I can do that if you like?