Hi, great job the new version!
But … a little “problem” viewing footnotes.
With the new version, not before, in some (many, quite all) footnote I can’t see the last line, unless I “enter” the note, that is I begin to write/modify the footnote.
I saved some images, with different zoom of footnote (110%, 125, 150).
Note that the last line is missing.
A single line note is not a problem (see 110), but long notes can be affected by the problem (see the same notes in 125 and 150).
However – the mystery increases – not always: in 110%, for example, the first note is visualised correctly – you can see the final dot – whereas the footnote 45 is incomplete.
It’s a bit noisy, and for my writings full of notes it is a great problem and I wish you could fix it.
… If I wanted to verify all notes quickly, the only way – I think – would be to export to Word.
No, please, no! Word no!
Thank you so much.
Please contact me if you need more information.
Regards.
Paolo Brambilla
MacBook Pro 2015, Scrivener 2.7, OSX 10.11. All updated.
I’m not seeing this problem (although I can clearly see it is occurring in the screenshots, I can’t reproduce it myself at the moment). Could you please send a project that exhibits this behaviour to mac.support AT literatureandlatte.com? Please be sure to zip up the project first.
Also, it looks as though you are on a Retina display - what about your friend? Is the problem on a Retina display for both of you? (I tried on a Retina but cannot reproduce it yet.)
Sorry for the late reply - we have two staff members on holiday, and I’ve had to write a 200-page document for our iOS developer over this past week.
Anyway, I have found the problem. The problem is that, when you’re not editing a comment, it is drawn using standard text-drawing procedures, whereas, when you are editing, a text editor draws the text while allowing you to edit it. This keeps things fast - it would be slow to have a different text editor always in place for every comment. However, it seems there’s a bug in Apple’s text drawing code whereby, for certain fonts, it doesn’t draw the line spacing exactly the same as the text view does (even though internally they should be using the same routines). This is what is causing the problem.
I have some ideas for how to fix this in the future (by using some of the backend code that the standard OS X editor uses for drawing), but for now, you can work around it by choosing a different font for your footnotes - Times New Roman seems to be the most problematic font, so choosing something like Helvetica will get it working fine. (Remember that you can override the footnote font for compiling, so what you use in the editor doesn’t have to affect the final text.)
This isn’t actually anything to do with El Capitan, 2.7 or Retina, incidentally - I could reproduce the same thing when using TNR in footnotes in 2.6 running on a regular display on Yosemite. So the bug must have always been there, but not many people must switch the font to TNR seeing as it hasn’t come up before.
Anyway, I hope that helps for now, and as I say, I’ll work on a proper bug-fix for the future.
Your reply is clear and I can understand the problem.
Your suggestion is smart, but for me incompatible.
In fact, I write my PhD thesis in Scrivener, following a complex settings of rules for publication. The name of authors must be Times New Roman small caps 12.
Scrivener can convert text to small caps – I think you know – converting to uppercase with different dimensions. So, my Author small caps 12 is really “A” (uppercase 12) and “uthor” (uppercase 9).
Overriding the font to TNR 12 in exporting (it is not possible to override only the font without number), all is uppercase, with a great waste of time to correct all authors.
I have written all my 150 pages with a large amount of notes in TNR.
Probably I could write in Helvetica, changing font before exporting.
But also this is a “time-consuming” way, because every written note must be manually changed.
So I hope in a bug fix (and I hope not too delayed …).
As Keith says, this is an Apple problem, not a Scrivener problem. Nisus have posted an FAQ about it saying the same thing, and that TNR is the worst affected, and that the problem is there even in TextEdit. Martin says that with TNR, if you use 2.0 line spacing — as opposed to a fixed 28.8 point spacing, or whatever — the actual spacing will be out by +5%, which will make your manuscript longer than it should be.
I hope Keith can find a work-around within Scrivener, but I would guess it’s likely to affect the compiled output too as you have to use TNR.
I would suggest your best bet would be just to use an alternative font, like Helvetica, for the footnotes within Scrivener, keeping your main text in TNR, and then setting the font override for footnotes only to TNR on export, and then sort any problems out in Word, OO/LibreOffice or Mellel — NWP won’t help here — as they use proprietary text-engines that, presumably, aren’t affected by this bug.
You can also set your “Author” small caps to “preserve formatting”, which might help.
Keith, thank you for the answer. I have to disagree, too. The problem occurred after I updated to El Capitan and to version 2.7: previously I had not such an issue. Which is a small one, but very annoying, as Paolo says. The issue is solved if you adopt a particular font. Not many: Helvetica (not Helvetica Neu), Courier, Lucida. It seems that the problem has to do with serif-ed fonts.
Hope you find a solution…
Thanks
Perhaps El Capitan exacerbated the problem, as it renders line spacing very slightly differently from Yosemite, but the bug was lurking on 10.10, too, and it is unfortunately an Apple bug. As I say, I have an idea for a fix, but it’s not something I can implement quickly.
Ok.
As especiale, I couldn’t experience the problem on 10.10. I remember, modifying the notes, a little change in dimension, but the last line was always visible with TNR. Probably it depended on the screen resolution.
So we wait for the fix. I hope not so late …
But, only to ask, couldn’t be possible to ask Apple to fix the bug?
If it is a Apple’s bug, affecting also Nisus (and I think other softwares), Apple can be interested in checking it.
Paolo
The issue has not been solved with El Capitan update (10.11.1). I have discovered that if I use Baskerville as the font for footnotes and comments the problem seems to disappear.
Just to let you know that I’ve moved this fix up to the next free update since it is causing so many problems for you. As I say, though, it was a bug that was lurking prior to 10.10, even if you couldn’t reproduce it - it just became more obvious on 10.11 because of text rendering changes by Apple. (There’s not much point in asking Apple to fix it, as they’ll just tell me to do what I’m already doing in my fix and draw the text in a different way; reporting bugs to Apple is usually frustrating and fruitless, as 80% of the time they’ll just say it’s expected behaviour or ask you to do all the work for them, then they won’t do anything about it for four years. The number of major bugs I have reported to Apple that are still sitting there unfixed is pretty shocking…)
I’ve had a similar problem with inspector comments/footnotes being visually truncated one line above the bottom of the bounding box, though if I clicked in the comment, the rest of the text immediately appeared. In my case, the font I had always used for such things was Optima. I changed it to EBGaramond and lo and behold, the empty line problem was solved.
But I’ve found another font problem. For one of my projects I’ve been using Athelas, an attractive font also available on the iPad in iBooks, for instance. Last week, I did a complete, clean re-install of 10.11.1. I now find that even though Athelas is apparently there in the System Font Library, it doesn’t come up in any font selector in Scrivener, either 2.6 or 2.7, NWP, TextEdit and even FontBook cannot find it.
Seems to me that there are real wierdities in the font system in El Cap!
Athelas is installed but not accessible because locked by Apple. You must transform it (search for it in your Library/Fonts) from tcc. Here you find how: transfonter.org/ttc-unpack
Have a nice day
Thanks, I’ll give that a try when I have a moment. The odd thing is that all the other .ttc fonts appear normally in FontBook and the various apps, so what’s so secret about Athelas that they’ve locked it? As it is accessible in Pages, perhaps they only want us to use it in their own apps … which I still find a bizarre decision.
The truncated footnote in inspector problem also appears in the Scrivener Tutorial with default settings in Scrivener 2.7 on OS X 10.11.1. The font used there is Optima Regular 10.
says, this is an Apple problem, not a Scrivener problem. Nisus have posted an FAQ about it saying the same thing, and that TNR is the worst affected, and that the problem is there even in TextEdit. Martin says that with TNR, if you use 2.0 line spacing — as opposed to a fixed 28.8 point spacing, or whatever — the actual spacing will be out by +5%, which will make your manuscript longer than it should be.