Scrivener 2.0.2 now available

User avatar
KB
Site Admin
Posts: 20113
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Mon Nov 29, 2010 4:26 pm Post

Hi all,

Just to let you know that Scrivener 2.0.2 is now available for download. This is a free update for all registered users of Scrivener 2.0. Although 2.0.1 was only released on Thursday, I received hundreds of crash reports over the weekend while I was away, most of them down to a bug I had introduced in the compile panel. Thus I thought I'd get this out to everyone as soon as possible. The changes are as follows:

  • Fixed bug introduced in 2.0.1 whereby Scrivener would crash when you selected “Custom” as the Compile format (and in various other situations when using the Compile sheet).
  • Changed “Copy without Inline Annotations or Footnotes” to “Copy without Comments and Footnotes”, and fixed bug whereby the links to inspector footnotes and comments would not get stripped when using this option.
  • Scriptwriting elements no longer show project auto-complete list items if “Include project auto-complete list” isn’t ticked for the element.

To download Scrivener 2.0.2, either:

  • Select "Check for Updates" from the Scrivener menu within Scrivener itself and follow the on-screen instructions.

Or:


If you have already seen the update notification and followed the on-screen instructions to update, you don't need to do anything else.

For 2.0.3, my plan is to start using the "Beta Testing" section of the forums again to release some public betas before it goes live (but 2.0.3 won't be for a good few weeks yet, so please no questions about when it will be :) ).

All the best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

da
davidblistein
Posts: 145
Joined: Sat Mar 20, 2010 12:27 pm

Wed Dec 01, 2010 2:42 pm Post

Hey Keith: Is there a reason that "Check for Updates" is grayed out on my main Scrivener Menu? I'm "still" running 2.0.1. I could upgrade through the Home page as you also suggest…but a little concerned that it might think I already have 2.0.2 and might screw something up in some mysterious way. Thanks. David

User avatar
AmberV
Posts: 22041
Joined: Sun Jun 18, 2006 4:30 am
Platform: Mac + Linux
Location: Santiago de Compostela, Galiza
Contact:

Wed Dec 01, 2010 8:06 pm Post

There is no harm in downloading from the web site and updating manually.

I'm not sure why this is greyed out though; never seen that happen before. It isn't a case of the program thinking you are already updated---it doesn't check to see if there are updates before it checks to see if there are updates, in other words. :) Even if you run it and you are up to date, it will still be available to try again. I tried disabling my 'net connexion to see if it detects that, but it doesn't. Does this condition persist after a relaunch?
.:.
Ioa Petra'ka
“Whole sight, or all the rest is desolation.” —John Fowles

User avatar
rahar
Posts: 10
Joined: Wed Mar 24, 2010 8:46 pm
Location: Nottingham

Thu Dec 02, 2010 12:41 am Post

Hello,

thank you for the fix! :-D

I've got a question.
I've absentmindedly accepted the automatic upgrade and Scrivener did indeed upgrade to 2.0.2.

I said "absentmindedly". That is because I prefer to manually update my software, when I can. I also like to store the DMGs of what I have on my mac. Just in case.

I noticed, however, that the 2.0.2 version which comes with the manual download is smaller. 10MB smaller. The inner structure of the package is slightly different and it seems to have been last modified later than the automatic update.
Which one is better?

Thank you! :-)

User avatar
KB
Site Admin
Posts: 20113
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Thu Dec 02, 2010 10:18 am Post

There's no difference between the one that comes by automatic update or the one on the DMG - the automatic update just downloads a zipped-up version of the exact same file that is on the DMG. So there shouldn't be such a file size difference.
All the best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

da
davidblistein
Posts: 145
Joined: Sat Mar 20, 2010 12:27 pm

Thu Dec 02, 2010 12:02 pm Post

Thanks, Amber. Upgrade went fine. And after the upgrade, the "problem" of the grayed-out "check for updates" went away (not after relaunch). So no big deal. I check for upgrades automatically anyway…just thought it was strange. David

User avatar
rahar
Posts: 10
Joined: Wed Mar 24, 2010 8:46 pm
Location: Nottingham

Sat Dec 11, 2010 7:43 pm Post

[quote="KB"]There's no difference between the one that comes by automatic update or the one on the DMG - the automatic update just downloads a zipped-up version of the exact same file that is on the DMG. So there shouldn't be such a file size difference.
All the best,
Keith[/quote]
Hello, sorry for the late reply.
I am afraid that they really are different.
http://img543.imageshack.us/img543/4435 ... 1at200.png
On the left the automatic update one. On the right the DMG one.

They both seem to work, but I'm still curious about the difference.

User avatar
KB
Site Admin
Posts: 20113
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Mon Dec 13, 2010 9:56 am Post

Actually, I looked into it a little more and it seems to down to the zipping methods used. Because Sparkle update zip files need to be code-signed, I built a small utility program that automatically zips up Scrivener and does the code-signing. It uses the commandline zip tool to compress Scrivener, and this was the issue. I wasn't using the -y option, so symbolic links were getting expanded and turned into the underlying files, meaning some files were appearing twice. Now that I've added that option, though, the updater version of Scrivener ends up smaller rather than larger, because the zip utility compresses some image files to be smaller, even unzipped, than they are in the original, and so far I've had no luck preventing this even with the -n option. Who knew using the zip utility would be so complicated...?

Best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

ep
epo
Posts: 25
Joined: Mon Jun 02, 2008 7:19 pm
Platform: Mac
Location: Edinburgh

Mon Dec 13, 2010 5:36 pm Post

FYI on my OSX 10.6.5 system, zip -n of a jpeg does the right thing. The invocation used was

zip -n .jpg zipfilename list-of-files-to-zip
or
zip -n .jpg:.png zipfilename list-of-files-to-zip

The '.' before the extension seems to be optional so
zip -n jpg zipfilename list-of-files-to-zip
also works. The space after the -n also seems to be optional in this case, in fact I couldn't get it to misbehave.

This is zip 3.0, adding -v to the command line will increase the verbosity and give a commentary on each file and the compression applied to it.

User avatar
KB
Site Admin
Posts: 20113
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Mon Dec 13, 2010 7:24 pm Post

Hmm, maybe it makes a difference if you are zipping a directory or a list of files - my guess is that the -n command isn't recursing into directories and may only get applied at the top level. Try this:

1) In the Terminal, navigate to a folder with a copy of Scrivener in it.

2) Type:

Code: Select all

zip rqyn .tif:.jpg test.zip Scrivener.app


Or:

Code: Select all

zip -r -q -y -n .tif:.jpg test.zip Scrivener.app


You'll end up with a zip file that is 38MB. Unzip it, and the unarchived version of Scrivener is 55.6MB version, whereas the original is 64.8MB - and the discrepancy is caused by the extra compression of image files. I don't seem to be able to find any way to prevent the zip utility from compressing files inside the /Contents/Resources folder (even -0 for "Store only" results in a file that is 55.6MB...).

All the best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

User avatar
rahar
Posts: 10
Joined: Wed Mar 24, 2010 8:46 pm
Location: Nottingham

Tue Dec 14, 2010 9:03 pm Post

Oh, I see.

Thank you! :-)

ep
epo
Posts: 25
Joined: Mon Jun 02, 2008 7:19 pm
Platform: Mac
Location: Edinburgh

Wed Dec 15, 2010 4:01 pm Post

Keith,

tl;dr you've got two different file extensions for tiffs, .tif and .tiff

Your no-compress only mentioned .tif so the others were being compressed. It should be:

zip -q -r -y -n .tif:.jpg:.tiff test.zip Scrivener.app

Then i get
74328 -rw-r--r-- 1 epo admin 38053161 15 Dec 15:44 test.zip
before I got the smaller file
74288 -rw-r--r-- 1 epo admin 38033707 15 Dec 15:48 test.zip

I discovered this in two stages first I changed your incantation (to remove -q and add verbose output) to:

zip -v -r -y -n .tif:.jpg test.zip Scrivener.app

this produces loads of output so I narrowed that down to lines mentioning .tif by

zip -v -r -y -n .tif:.jpg test.zip Scrivener.app|grep tif

This was still too verbose so I excluded all lines showing non-compressed files (contain the string '0%')

zip -v -r -y -n .tif:.jpg test.zip Scrivener.app|grep tif |grep -v '0%'

and got loads of .tiffs listed, adding ':.tiff' to the list eliminated all those, you probably also want to add ':.jpeg:.png' for safety.

User avatar
KB
Site Admin
Posts: 20113
Joined: Tue Jun 13, 2006 11:23 pm
Platform: Mac
Location: Truro, Cornwall
Contact:

Wed Dec 15, 2010 4:26 pm Post

Hmm, nope, for me that still results in a file that is 55.6MB rather than 64.8MB, even including .tiff (I'd already checked that some of the .tif files were still being compressed, I believe).

All the best,
Keith
"You can't waltz in here, use my toaster, and start spouting universal truths without qualification."

User avatar
robertdguthrie
Posts: 3075
Joined: Mon Nov 09, 2009 10:06 pm
Platform: Mac
Location: St. Louis, MO, USA
Contact:

Wed Dec 15, 2010 5:31 pm Post

Does this extra compression cause any issues/degradation of the graphics files? If it's non-destructive, maybe part of your release work flow could include using the zip utility to compress and then uncompress the application. With that as your starting point, I would assume you could get the same (smaller) installed size no matter what distribution path you choose.

ep
epo
Posts: 25
Joined: Mon Jun 02, 2008 7:19 pm
Platform: Mac
Location: Edinburgh

Wed Dec 15, 2010 6:25 pm Post

How odd, the files are identical (have the same contents) but occupy different amounts of disc space.

As a sanity check I tried to package up the file with tar, on unpacking the directory sizes were indeed identical.