I am seeing white lines through a row of text when scrolling down a file using the scroll bar or the scroll wheel on the mouse.
The problem starts about 1/3 of the way into your ReadMe file, if that helps you identify how far I have to go before I have the problem. It seems to happen more often as I go farther down the file.
I tried changing font and line spacing and had the same problem, though it was less noticeable with Courier as the chosen font. This doesn’t happen in full-screen view so far as I can tell.
I believe this is a Cocoa text system bug as opposed to a bug specific to Scrivener. It has been reported before, and I have seen it in other Cocoa programs too. However, if anyone can isolate it, I will take another look, though given that Scrivener does nothing (in fact it forces more of a redraw rather than less of one) that should cause this, and given that I understand that there is a general view bug across OS X, I am inclined to think that OS X is to blame rather than Scrivener. I hope so, anyway.
If it’s an Apple problem, I understand. Some things we just live with. I did look at the earlier posting about the problem and it seemed you weren’t sure about the cause at the time, so that’s why I’m following up here.
For what it’s worth, I checked the file at various screen magnifications and found the following:
90% - multiple lines not written correctly when scrolling, starting about 1/3 of the way down the file.
100% - all okay
110% - multiple lines
125% - all okay
150% - maybe 2 lines
175% - multiple lines
I think 90% was the worst, followed by 110%. I did try changing font sizes and had about the same results at the same magnifications (with 100% and 125% being okay).
I won’t belabor the point - it isn’t that important, and it doesn’t detract in any way from my overall impression of the program. It’s great!
Hmm… It may be that zoom affects this, but I still think it is an Apple bug that is only exasperated by the zoom factor. I will take another look at the code, though. Zooming in text views is always somewhat problematic because there is no standard way of doing it. I wonder if the same bug appears in DevonThink when zoomed… Anyway, if you do want bigger text, remember that you can just enlarge the font you use in the editor but use a smaller font for exporting. Generally I never use zoom because I just use my preferred font settings in the editor…
Thanks,
Keith
Thought I should throw this into the discussion - it may be relevant.
Esoteric, I know, but assume you are working in a 12 point font.
If 12 point = 100%, then a 13 point version of that 12 point font = 110.83333% and 14 point = 111.6666%, and so on.
There is not a perfect correlation between point size at 100% and decimal magnifications. So fonts that are reduced or enlarged may be trying to do calculations that would try HAL and are always a bit iffy.
Better to choose a size you like, rather than a magnification - exactly as Keith suggests. There is a mathematical reason for such a choice. All original sizes are exactly 100%. So choose something at 100% font size and work with that - rather than a magnification.
The Final Draft people developed their own version of Courier and it seems to work quite well with percentage magnifications.
PS: I recall that AmberV suggested another couple of reasons (in an earlier post) for fonts being a problem - bit map problems and just plain faulty fonts. Fonts can do all sorts of weird things to your applications that just do not look like font problems. FontDoctor, or some such, is really a good investment if you get strange problems that persist when other fault finding methods have failed.
I have the same problem, but I can hardly believe it is caused by the zoom. I’m working daily with Mellel at 175 / 200 % zoom, and with DT Pro at various zoom levels; and I never experienced the problem there.
By the way: these white horizontal lines who seem to ‘break’ the characters disappear as soon as I click in teh winddow.
If you are experiencing this problem, please could you do me a favour? In Preferences, under Text Editing, set the margins for both Left/Right and Top/Bottom to 0 and see if this fixes the problem. I have a feeling it might be to do with the scaling of the margins rather than of the text itself. With initial tests this seems to make the problem go away (and would explain why other programs don’t have the problem, seeing as most don’t have such margins - and Mellel is a different beast altogether). So, it may be a problem with the margins code, but I really need this confirmed by those of you who can reproduce this problem before I can say that I can fix it. If setting margins to 0 fixes this for you, then I will know that I have to amend that code slightly.
Thanks,
Keith
I tried setting the text margins to 0 and don’t see any white lines at 90% or 110%, so this seems to have solved the problem. Good news!
I did try changing font sizes, rather than zoom, and found that I had trouble reading text at 12 and even 13 pt. sizes (too small for my eyes). Going to larger point sizes makes text darker and less clear for me. A zoom level of 110% plus the lower font size givess the most viewing comfort, so that’s why I have been using it.
Identical experience here! I set both margins at 0, and then saw no white lines anymore at 175% (Times 14). Subsequently, I set the margins back to 40 / 20, and the white lines immediately returned! So this seems indeed the key to the solution of the problem!
This is good news… Sort of. It means that we have a workaround, though I’m not sure how to fix it. The Cocoa method used to set these margins is called “setTextContainerInset”, and this is a small note I found in the Cocoa docs for this:
I am wondering if this is the source of the problem. I will experiment with this and see if there is anything that I can do to fix it inside Scrivener - otherwise it may just be that users need to experiment with different margins and zoom levels (not ideal, but at least it works for now). I have posted a question on the Cocoa list to see if anybody knows more about this.
