Hi everybody,
I'm using font-face with multiple fonts, on Twine 2.1.0. The fonts are stored on a server and the link specified in CSS url is with an absolute path to this server. I'm absolutely sure it works cause fonts aren't installed on the system, It has to download it from the server.
It works fine in Twine but once I export a HTML file, font-face doesn't work anymore in the browser (Firefox).
Any idea ?
Thanx,
PS : So, I get a black blank screen on Edge with some Twine HTML exported files (Yes I know it's popular to bash MS browsers, but Edge isn't IE anymore and really do pretty fine on a lot of things, so...)
Comments
What does your CSS look like?
But yeah, I can only speculate before you provide more detail.
1. The browser can't obtain/load a required resource (eg. a Font file).
There is not much SugarCube can do about this itself because it's in the domain of the web-browser, although the Author could delay the loading of those resources until after a generically styled screen has been shown to the Player.
2. The story fails to start due to an error in the Author's code.
Hopefully these types of errors are caught by the Author's user-testing and never reach the Player, although it can be hard to fully test each of different web-browser / operating system combinations in use today.
3. The story fails to start due to an error in the story format itself.
In this case it is unlikely that the Author's custom styling will be applied to page so it is a mute point.
The loading of resources over the network isn't something that either SugarCube or the project developer has much control over. The developer does, however, have control over how that can be hidden from the player, either by using a custom splash screen or leveraging SugarCube's own loading screen—there are a few different options available for the latter.
If the project developer does nothing to hide any flashes of unstyled content (FOUC)—that's the term for what we're discussing—then that's hardly the fault of the story format—any story format.
Assuming you're talking about the style sections managed by Twine—Story Stylesheet (Twine 2) and stylesheet-tagged passages (Twine 1)—then that is incorrect. Injection of the story CSS in SugarCube is, literally, one of the first things to happen—only the initialization of the storage and UI subsystems occur before that.
I'm unsure what you're getting at with the latter. Assuming that the resource is being loaded correctly in the first place, then something going wrong during its load over the network—e.g. being unreachable—is something that neither the browser, story format, nor developer have virtually any control over.
How exactly does it count as shifting the goalposts when I didn't specify one way or another initially? How exactly does it count as shifting the goalposts to bring up new details I didn't think of initially? How exactly is it bad to think of this from the perspective of a player, who DOESN'T FUCKING CARE about this sort of technical details, and shouldn't have to?
Oh wait, presumably whoever is making something in Twine is expected to be a developer, with the requisite mindset and knowledge. EXCEPT, you know, that's a PROBLEM Twine was designed to SOLVE. And it doesn't. It's failing at it pretty badly, actually, the moment you try to do anything more than create passages and link them together. Never mind that even as a developer, if I have to think about every little detail anyway, then I might as well roll my own engine.
Tell me, how exactly does it help the original poster to invoke debate rules, as if we were having a medieval trial? At least I was trying to brainstorm probable causes, and yes, when you do that sort of thing you're going to come up with some pretty stupid ideas among the good ones. My apologies for DARING TO BE WRONG.
Curious, then, how in my experience. every single time a Twine game loads, the first passage appears and only then any remote font is applied -- driving the browser to reformat. You'd think the font file would have been cached after the first load, but it never seems to be. Of course, failure to cache is more likely due to a misconfigured server. But that can't be fixed in CSS any more than it can be fixed in the Twine core. It could be fixed by saving the font file locally and shipping it with the game (assuming the license allows it), but that complicates distribution considerably.
But that's assuming the remote font actually does load. (It never failed for me.) Frankly, the original description sounds like the kind of weird bug that keeps web developers in long past office hours. And in cases like that you never know what tidbit of information about how the software works might turn out to be of help.
If it is somehow a loading problem, there are ways to solve that. Simplest way to get a definite answer is to provide your code though. Use the little C on the forum's toolbar so it formats right.
As has been noted, this line of discussion has strayed from the topic at hand, so if you wish to continue this further, feel free to send me a PM—though, I will ask you to dial it down a notch.
I'm 100% certain that the issue is not that the CSS is only applied later.
My game uses custom CSS for everything, and if it were to load the CSS only after the first passage, then the game would flash a lot more than the fonts. But the entire look of the game does not suddenly change at any time.
My approach to solve loading issues is to have a designated loading passage that displays something else other than the text passages on the screen for however many seconds you need to load the game.