When I export a compile of my project using the Screenplay format mode, the resulting PDF has large portions of gobbledygook text (random characters).
Any ideas what this could be? Interestingly, this is happening in both my working Scriv vers, and the beta new v.3
Any ideas anyone?
I’ve heard of this happening if Courier Prime is installed, I would try uninstalling that font and giving it another try.
Thanks for the reply.
Installed in the software or my computer?
I f the former, ow do I uninstall? If the latter, this is a bit of a problem for all other applications and a bit of an unreasonable workaround, no?
Cheers.
Yes, on the computer or user account, there isn’t a way to install fonts into the software.
I meant it as something to try. Whether it is something to live with is your choice, based on whether or not it is reasonable I’m sure. It should be relatively easy to live with it, and the bug, as I think the problem can be dodged entirely by compiling to RTF instead of PDF.
Thanks for the reply.
Ummmm, I don’t think it is easy to live with (I mean, relatively of course there are bigger problems out there) - this is a professional writing software that is throwing up a bug, the solution to which is to uninstall the most widely used scriptwriting font in the industry and not export to PDF, but to RTF instead? Which destroys the formatting, actually, and needs to then be fixed in another software.
I don’t think this is an acceptable or pragmatic solution. It’s too big a part of this software and writing in general.
Is it not possible to try to fix the bug? If there is such an issue at such a fundamental level with THE used font in the trade, then it is almost pointless using the software, I’m afraid. Which is a shame because I really like it.
Is this bug at least going to be fixed in the new version?
Just for clarification, to export to RTF, then import into FadeIn or Word and try to refix the broken formatting takes about an hour. Are you proposing I do this for every draft or preview (since the only way to preview the script properly in windows is to export to PDF)?
I don’t have that kind of spare time.
Have you checked this out? [url]https://forum.literatureandlatte.com/t/footnotes-compiled-to-pdf-corrupted/93881/2]
Surely this has to be addressed a bug. No?
Not working for me. The garbled text has gone, but it has been replaced by italics as the standard.
Why is such a major and fundamental bug still present in a professional writing software? I don’t get it.
I’m having to go through the doc and manually select each paragraph (different formatting throughout so can’t select all, which you can’t do because of Scriveneings mode anyway) and change IN MENU (not hotkey) from italics (in standard mode) back to standard (by selecting standard mode again).
Honestly, this is ridiculous. Maybe there is a better way of manually fixing this via the underlying code or something, but I’m not a programmer, I’m a writer, and this is really testing my devotion to this software and calling into questing its usefulness.
That took me an hour. And I’m still getting errors in the compiled PDF.
What do you propose, Scriv team?
Any further solutions Amber?
Sorry to say, I was only trying to help by relaying troubleshooting steps I’ve heard other people saying from threads, such as the one you were linked to above.
Generally speaking when you have a large piece of software that is working together with other large pieces of software to perform an extremely complex operation, the likelihood for there being difficult to solve mismatches between the systems will increase, particularly when you start stressing areas of that integration that are seldom used. It’s one of those things that is pretty much impossible to avoid, like genetic failures in living organisms becoming more likely the more complex the organism. As I understand it, the data is being passed to the PDF conversion engine as best as we can, but it is producing an invalid result.
To me this all seems relatively easy to avoid by compiling to RTF and generating the PDF elsewhere, however, at least until they can get it solved or the developers who ultimately make the PDF generation code can get it fixed on their end.
Hi Amber,
Thanks for offering explanation.
I still don’t really see that this is a valid excuse. This is a fundamental aspect of this software, and it is not working. If an editing software is producing errors on export, or a 3D software is producing errors on render, which are experienced by multiple users and seems to be a ubiquitous failing of the software, it is big problem, and I would posit one the developers need to fix as it means the product is not fit for use. You can blame a road for a car not working, but my road is a completely new (Windows 10, high spec computer, only essential, professional software installed), high standard regs motorway, and has no trouble facilitating many other cars.
The RTF workaround is possible, but it is not easy (formatting errors) and is not a viable solution for me.
This bug needs to be fixed by the developers, or else the company is simply accepting that a big part of the software doesn’t work, and that is odd.
Is anyone from development going to reply and give me a diagnosis or timeline of when I can expect a fix? Are you officially in the development team, Amber?
Is this bug going to be fixed in new version? If not I am going to have to switch to another software, again, which I really do not want to do.
It seems to me that the only workaround to this is to use Courier Screenplay font instead of Courier Prime.
This is a very situation having to veto the industry standard font, but at least this alterative is feasible until it is fixed - which it will have to be if Scrivener wants screenwriters to use this software.
I really hope it will be fixed for the new Windows release.
Seems I’m being ignored. Okay, so just back to emailing support instead of flagging things up here then.