Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

using font-face in Twine and exported HTML file

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

  • You should always state the story format you're using and its version, because advice will tend to vary based on that information.

    What does your CSS look like?
  • Also, when something doesn't work in the exported story file, it's a good idea to peek at the browser's developer console. Maybe you're using some CSS that only works in browser engines from the WebKit family? Or perhaps there's a timeout. In my experience, Sugarcube 2.x takes its sweet time loading and applying remote fonts, even after the game has finished initializing.

    But yeah, I can only speculate before you provide more detail. :)
  • felixp7 wrote: »
    […] In my experience, Sugarcube 2.x takes its sweet time loading and applying remote fonts, even after the game has finished initializing.
    Loading resources over the network has, literally, nothing to do with SugarCube. It takes however long it takes for the browser in question to download and apply the style. This is not something SugarCube has a hand in.
  • edited March 2017
    Loading resources over the network has, literally, nothing to do with SugarCube. It takes however long it takes for the browser in question to download and apply the style. This is not something SugarCube has a hand in.
    Yes, I know. But that has nothing to do with the way a player perceives it. Presumably the story CSS is only injected after the game has been initialized and the first passage already displayed. But imagine if something goes wrong at exactly that point.
  • felixp7 wrote: »
    But imagine if something goes wrong at exactly that point.
    Things that can wrong at that point can generally be broken down into three groups:

    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.
  • felixp7 wrote: »
    Yes, I know. But that has nothing to do with the way a player perceives it.
    The way it's perceived by players was not part of your original assertion—shifting the goalposts ex post facto is a crummy thing to do, by the way.

    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.

    felixp7 wrote: »
    Presumably the story CSS is only injected after the game has been initialized and the first passage already displayed. But imagine if something goes wrong at exactly that point.
    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.
  • The way it's perceived by players was not part of your original assertion—shifting the goalposts ex post facto is a crummy thing to do, by the way.

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

    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.
  • edited March 2017
    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...)
    This post has gotten a little out of control. Anyway, can you show us the code you're using in your CSS?

    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.
  • This thread is becoming uncivil (profanity and caps is, to say the least, unnecessary) and off-topic. Please, everyone, let's keep to tamantafamiglia's original question.
  • felixp7 wrote: »
    How exactly does it count as shifting the goalposts when I didn't specify one way or another initially?
    1. The statements in your original post never once mentioned, or implied, anything about user perceptions. Not once. You, specifically, made an assertion about SugarCube v2 being slow at loading/rendering/whatever. Prefacing that with "in my experience" doesn't change the assertion, nor does it imply you were speaking more broadly about user perceptions in general.
    2. I replied to that original assertion with a clarification.
    3. You then replied that my clarification had nothing to do with the way players perceive it, as if that had been part of the discussion from the beginning.
    I have no issue with you bringing up user perceptions. That is an entirely valid line of discussion. Bringing up afterwards in a way so that it seems as though it had been a part of the discussion all along, when it categorically had not, is not the way to go about it.

    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.
  • edited March 2017
    felixp7 wrote: »

    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.

    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.
Sign In or Register to comment.