Hi… I’m sure I’m just missing something blindingly obvious with this but here goes…
For some reason I’m no longer getting the expected result when exporting a Hype doc that has been configured to scale to 100% width. Everything looks exactly as I’d hope when previewed. However, once the doc is exported as a folder the 100% width scaling doesn’t work. I’ve created a super-simple example to illustrate (screenhots and zips attached).
If anyone can shed any light on what’s going on, your thoughts and advice will be most welcome
Nope, good suggestion but I’ve already double-checked and it’s definitely not that.
It’s a quite a mystery
For now, I’ll need to find a different way of doing things for the actual project I’m working on as I’m on a deadline with no time to find a fix… but it’d be cool to get to the bottom of this at some point as it’s quite a blow to have inexplicably ‘lost’ the ‘scale width’ facility.
The reason I suggested this is because on my version of Canary and Chrome and Safari the doc scales to 100% width up to 1200px so I couldn’t see a problem
Many thanks for taking a look, @jonathan, it’s much appreciated.
I’m still trying to figure out what the issue might be. As-of yesterday, I’ve also begun experiencing some other ‘oddities’ (video footage loaded using inner html in a rectangle is visible in preview mode but not when exported); so I think it’s safe to assume the problem is at this end and (hopefully) not universal.
I’ve done some relatively recent OS updates (I’m using High Sierra 10.13.6); so I’ll check out what’s changed and see if I can trace any of the anomalies to the updates.
Will post back up if I find anything and/or discover any solutions.
There can be some differences in loading content if you are opening the export as a file:/// URL (typically double-clicking) compared to a http/https URL that preview or a live server may have. You may have some hints in the developer console. This doesn’t affect flexible layout, though.
Cheers… I generally have a look at all output as both file:/// and also via a web server; so I can get an accurate sense of how it’ll run when live. I’ll certainly have a thorough examination of the dev console info, to see if that flags up anything obvious.
Unfortunately due to increasing security restrictions over the last 10 years, file:/// URLs (opening as a file) are increasingly divergent from the behavior you’ll see when served. I recommend using a HTTP server if possible - there are personal ones that can be setup locally.
Of course, this might not be your issue at all, but it a likely culprit!
Thanks, again, for your time @jonathan … I generally use Web Server for Chrome but it doesn’t seem to address the issues I’m experiencing.
I definitely think there’s something anomalous going on locally with my OS.
I’ll keep hunting for the cause/causes as time permits - meanwhile, though, I’m adhering to the adage that there are a million different ways to achieve the same, or nearly the same, result; so I’m happily pursuing a different route to end output for the mo’
The suggestion was much appreciated, I kid you not.