Scrivener 2.0.2 now available

[KB]

It is strange - if you ctrl-click on Scrivener in the Finder and choose "Compress" to create the zip file, when you unzip that archive the file size is the same as the original. So it is just down to the command-line zip utility doing extra compression.

Robert - I don't know, to be honest. I imagine there will be some difference, but I don't know how noticeable it is - I haven't noticed any differences. I'd rather keep the automatic update version the same as the original rather than compress further, though.

All the best,
Keith

[AmberV]

Here is my theory, after doing some examination in Path Finder and Terminal. I took two TIFF files, one had ZIP compression applied to already, and the other had no compression applied to it. I wanted to see if the zip tool was actually adding zip compression to TIFF files, as unlikely as that would seem. The result of that test is: it's not. However I did get the curious drop in file size---not very large, but a drop. Test file one had 217,088 bytes prior to being zipped, and after being zipped it had 212,992 bytes.

I loaded both of these TIFF files into Photoshop layers and enabled the Difference mapping mode on the top layer. This produces a result which maps RGB(0,0,0) to zero differences. So for each pixel in the layer, it is compared with the composite of the pixel data below that layer. If the pixel data is precisely identical, the resulting colour will be black. If there is any deviation, it will be non-black. The result: a perfectly black image, meaning the two files are identical at the bitmap level, despite the drop in file size.

So went to Path Finder and examined the two files in depth. The report file generated for each was pretty much the same, excluding of course things like where the file is actually stored on the physical hard drive. Then I came across this line.

Pre-compression: Resource Fork Size: 286 bytes logical, 4,096 bytes physical
Post-compression: Resource Fork Size: 0 bytes logical, 0 bytes physical

There you have it. That most certainly accounts for the discrepancy. With the many hundreds of TIFF files in the Scrivener.app package, even if the byte counts are very small, they still have to use a 4kb block to represent it, so at minimum each file has 4kb of useless data which zip is stripping out. This amount will increase depending on your Photoshop settings. I have pretty conservative settings, but if you have it set to insert icons and other meta-data into the file, this number could go up pretty quickly.

My speculation is thus: the underlying filesystem link between a file's resource fork and data fork is considered by the zip utility to be a type of link, and so when the -y flag is used to not flatten links, the resource fork gets dropped. This probably, by the way, produces a zip file that is "nicer" for Windows users to look at. It might not have that MACOSX folder at the top which stores filesystem meta-data. Not that such is relevant to the Scrivener.app bundle.

[Jaysen]

Which is where FS tuning comes in. Reduce the inode/block size of the FS and the amount of empty data will go down.

But who really wants to rebuild an FS for this?

[AmberV]

I can't see why an casual or even semi-pro user would need to bother with tuning. Now, if you are capturing and writing raw HD feeds to a RAID-0, you would definitely want to tune, but in that scenario a larger block size is more advantageous at the IO level. I bet Apple just banks on the larger block size to make sure multimedia playback is skip-free for the majority of users, even though it does mean a large amount of waste.

[epo]

Given that dmg is the common packaging scheme for OSX why are zip files used at all? (BTW we know that tar seems to work.)

Keith, sorry for fixating on the tif-file-size red herring when it was the unpack size that was wrong.

EDIT: does the file compression discussion here help? http://xahlee.org/UnixResource_dir/macosx.html

[Jaysen]

Actually FS tuning is pretty key to a really responsive system. The 4k block is used as most "end user" files are well over 4k and so the slight bloat is not even noticed. The other advantage to a 4k block is read write optimization and cache. The slow drive is very good at reading a larger contiguous block of data which can be shoved to RAM for program use. Various media files and larger "project" files (docx) get big advantages with this.

Move to a slightly more obscure idea though, something like scrivener, and a smaller block size would actually be an advantage. Small chunks of text may not total 4K (most of my chunks are less than 400 words until I start compiling) so I am losing tons o' useable space if I have 200 scriv scenes. Take it a step further and virtual mem (typically raw actually or a loop back device that is access as raw) really needs the lowest block size possible. A web server that is highly loaded wants a small block size to allow for optimization of the drive caching and optimization of read (based on ability to flush buffer to client).

Which is my long winded way of saying normal folks have no idea what we are talking about and really shouldn't care. Right?

[rahar]

Whoa!
I couldn't imagine my curiosity would start this sort of discussion!

I've read everything (very interesting), thank you. :-)

[Jaysen]

At least we are still talking about something remotely related to your question. Normally we have already left "left field" and are well on our way to the ice cream stand by now.

[whodoneit]

I had a demo version of 1.53 and loved it and was waiting for 2.0 to come out to purchase. But I do have one question before I indulge. My spell check did not work with the earlier version and was wondering if that had been fixed for the new release. To give you some back round info I run snow leopard and it would mark misspelled words but would not give suggestions or fix them I would have to do that manually.

Thanks

[Jaysen]

Spell check has always worked for me so I can't tell you if it is fixed.

BUT you can DL and demo 2.0. Then you can be sure that it does everything you need it to do!

[KB]

2.0 also has an auto-correction option with 1.x did not have.
All the best,
Keith

[gr]

Wait. Did someone say "ice cream"?

[AmberV]

This sounds like you might be referring to a problem Snow Leopard has when using more than one language, and leaving the spell check engine on automatic. It will balk and not present most of the spelling engine functions when you right-click on a misspelled word. Does that sound about right? If you don't need multiple languages, try turning off automatic in your spell checker settings (this is a system-wide thing) and setting it specifically to the language you write in.

[janra]

I just checked and my spellcheck was set to automatic/by language. I had intermittent refusal to spell check; some character names in certain files would refuse to have the spellcheck context menu so I had to go searching for a file in which I could add them to the dictionary.

I'll see if this made a difference, but being intermittent, it will be hard to say for sure.

[ScrivenerBill]

Brilliant update