[Pro] MacOS Mojave obliterates the Caxton Action!

Freeway
1

In order to test what might happen when under MacOS Mojave, I decided to clone my High Sierra internal drive to an external SSD and then apply the Mojave update on that external drive. I’m now booted off that external drive and am testing various apps including Freeway Pro 7 in conjunction with my existing Freeway websites.

When I opened an existing document and then Published and previewed in the browser, I noticed that my web fonts were dead. I went back to Freeway and found that every instance of Paul Dunning’s excellent Caxton action on every single page on my document was gone!

For those of you not familiar with Caxton, here’s the action:

http://actionsforge.com/actions/caxton

I then did a search on my external SSD for Caxton and found it is still there, properly installed. I then went back to Freeway and used Insert > Action Item > Caxton to insert an instance on one of the pages in my site.

So a move to Mojave would require me to rebuild and reapply that Caxton Action item on all pages of my site, which seems a little ridiculous. I therefore am posting this new thread to see if we can determine what in Mojave is causing this to happen and see if it can be fixed. I’m not sure if it is a Freeway problem or a Caxton problem, but so far, Caxton is the only Action that was obliterated from all pages in all my sites under Mojave.

I look forward to hearing your thoughts and feedback, especially from you Mojave users and those of you who use Caxton to get Web Fonts to work on your Freeway pages.

Thanks!

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:

2

Oooops!

:slight_smile:

During the coarse of my investigation, I discovered that I actually obliterated Caxton some time ago due to issues I had back then. My sites now rely on hard coded @font-face code in css files!

So the problem has nothing to do with the Caxton Action but everything to do with Mojave + Safari 12.

The problem is that when I preview in Safari 12 under Mojave, @font-face breaks and all my custom fonts revert to generics. No such problem in Chrome or Firefox. And no problem in Safari 12 under High Sierra.

There is no problem viewing my custom fonts in Safari 12 under Mojave when I view my website from my web server, which is interesting. It’s only when I Preview locally from Freeway that @font-face breaks. Would any of you know why and what the work-around is?

Thanks!

freewaytalk mailing list
email@hidden
Update your subscriptions at:

3

When I Preview locally in Safari 12 under Mojave and then open the Console and show page errors, I see what is shown in the following ScreenShot:

https://cl.ly/1d0292c1d5e1/Image%2525202018-12-20%252520at%2525204.13.12%252520PM.png

(Ignore the first 2 lines since those errors occur even in High Sierra – if you know how to fix those, I’m all ears!)

And here is a ScreenShot of Console Errors from the same web page, Previewed locally in Safari 12 under High Sierra (no font errors at all):

The @font-face code used on my site is as follows:

/* font-face NOTE! use "/font" relative URLs ONLY!!! */

@font-face {
 font-family: 'Display Black';
 src: url('/fonts/Display%20Black.eot');
 src: local('☺'), 
   url('/fonts/Display%20Black.woff') format('woff'), 
   url('/fonts/Display%20Black.ttf') format('truetype'), 
   url('/fonts/Display%20Black.otf') format('opentype'), 
   url('/fonts/Display%20Black.svg#DisplayBlack-JP') format('svg');
   font-weight:normal !important;
   font-style: normal;

I’ve read that Safari 12 under Mojave operates differently than Safari 12 under High Sierra in that Mojave + Safari implements some improved tracking prevention features. Even so, when viewing my websites normally off my web server in Safari under Mojave, all is well with my custom web fonts. It’s only when Previewing in Safari from Freeway (in Mojave) that my web fonts break.

Again, if someone knows of a workaround for this, I’d love to hear from you! For truly, this is the only issue I’ve seen thus far while testing in MacOS Mojave.

Thanks,

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at:

4

I suspect the leadings “/“ is the problem. If you are going File>Preview, then that is probably breaking things. You’ll need to use a web sever, with the site at the root (the leading “/” means “start at the root directory”). File>Preview does not invoke a web server instance, it’s just a straight forward file preview. It’s possible that Safari is looking for the font files in a folder called “Fonts” somewhere at the top of your Hard Drive’s file structure. Your screen shots seem to confirm this.

Other browsers may be more forgiving of this problem, but Safari is actually doing it properly.

Take the first “/” out and see if that makes a difference.

For the sake of record, the Caxton Action drops in the tags with the references to the CSS file for the font, and manages the supporting files. However, you do need to be aware of such things in the CSS file as Caxton does not attempt to fix anything like this. You’ll need to crack open a text editor yourself.

One day, Caxton may be a bit more self supporting (when an Action can get file references based on the location of the CSS file, not the location of the current HTML page from Freeway), but right now, you need to be able to be sure that file references are correct, just like you need to in this instance.

My suggestion: Download and use MAMP, publish in there, and use your Browser to navigate to the site using http:// rather than using File>Preview. This is a habit I got into years ago, and I you get a much better idea of how the site will work, and little crinks like this should just vanish.

freewaytalk mailing list
email@hidden
Update your subscriptions at:

5

Paul, thank you for the tips.

I first booted into Mojave. Then using Text Wrangler, I manually deleted the “/” that appears before every instance of “/fonts” in my *.css files contained in my Site Folder, such that the code now looks like this:

/* font-face NOTE! use relative URLs ONLY!!! */

@font-face {
 font-family: 'Display Black';
 src: url('fonts/Display%20Black.eot');
 src: local('☺'), 
   url('fonts/Display%20Black.woff') format('woff'), 
   url('fonts/Display%20Black.ttf') format('truetype'), 
   url('fonts/Display%20Black.otf') format('opentype'), 
   url('fonts/Display%20Black.svg#DisplayBlack-JP') format('svg');
   font-weight:normal !important;
   font-style: normal;

I then double-clicked the index.html file in that same Site Folder, which opened the site in Safari (accomplishing the same thing as a Freeway in-browser Preview). Same problem. All my custom fonts appear as generic fonts. And now the Safari Console error list looks like this:

https://cl.ly/19256ee708c1/Image%202018-12-21%20at%209.39.58%20AM.png

Again, this problem does NOT occur in High Sierra, or Sierra or earlier MacOS versions, even when I use that “/” before “fonts” in my CSS files.

Safari 12 + Mojave adds some kind of anti-fingerprinting privacy features, and I wonder if that is messing around with my web fonts. But if it is, why then would it affect only local viewing (such as when I use Freeway’s Preview) and not affect my web fonts when I view my website normally (accessing from the web server)?

I have my fonts hosted on my web server within the root directory (root of <public_html>), inside a folder named “fonts.” So there is no “fonts” folder inside my Site Folder that Freeway creates locally on my iMac. But that’s never been a problem before when running High Sierra and earlier version of MacOS, and its still not problem when I use FireFox and Chrome under Mojave. It’s only Safari under Mojave that gives me generic fonts when I Preview from Freeway.

When I load Chrome or Firefox under Mojave, with or without that “/”, I can see my web fonts just fine. The browser is obviously accessing the fonts locally from my iMac in this case, because like I said, there is no “fonts” folder within my Site Folder on my iMac. So Safari under Mojave isn’t accessing my local fonts like FF and Chrome are.

I’m surprised that I’m the lone soul reporting this. Surely others among us have updated to Mojave and have done a Preview from Freeway using a site that has web fonts. I would expect others doing the same thing I am to see the same problem.

Any further ideas about a workaround to this problem would be appreciated.

Thanks,

James W.

freewaytalk mailing list
email@hidden
Update your subscriptions at:

6

I have no idea why Safari isn’t working like this - but I don’t think this is the problem. I think it’s being more strict about stuff, so you need to be more specific about the locations of resources.

OK, put the full http:// URL to the fonts then. The browser is using file:/// to locate every resource, including the font files, which is what is used using to locate the font files in both this instance AND your original post. So it’s looking on your computer’s HARD DRIVE, not elsewhere in internet land. It’s certainly not invoking a server.

The error console is key here - that tells you what file is missing and WHERE Safari thinks it should be and what protocol it’s using to look for it. It is your friend, and it will help you solve this problem.

I’d seriously suggest:
a) Making sure your font files are in the Site Folder, not somewhere else. It will make it easier to track down this kind of problem
b) Using MAMP or another web server to preview on instead of File>Preview in Freeway. If you are doing anything remotely exotic like this, then that can help a lot in tracing errors and helping to fix them

freewaytalk mailing list
email@hidden
Update your subscriptions at:

7

The rule is that when working with @font-face, uRLs must be relative. So I cannot put the full URL into my CSS file. Believe me I’ve tried to put the full URL in, and when I do it breaks my web fonts everywhere.

As to the suggestion of having Freeway upload my “/fonts“ folder every time, I’d rather stick with High Sierra than do that because Freeway dirties every single page in my site every time I use Freeway! My fonts never change, so it’s a waste of time for me to have Freeway upload them every time the page gets dirty. The fact remains that everything works perfectly when I use High Sierra.

Anyway, thank you, Paul, for the advice.

James Wages

freewaytalk mailing list
email@hidden
Update your subscriptions at: