GNOME Bugzilla – Bug 740338
Font and line/paragraph spacing improvements
Last modified: 2015-12-13 21:00:36 UTC
Some assorted font changes that would improve the overall appearance: * Use the system document font by default. Right now, Notes uses the system UI font by default - Cantarell. This is primarily intended for the UI, and not documents. There's a separate document font which would look better. * Increase paragraph spacing. This will make it easier to distinguish paragraphs when the lines wrap. * Use the same line and paragraph spacing in the note thumbnails, as in the notes themselves. This will make the thumbnails easier to read, and the additional consistency will give a more cohesive experience.
I've discussed this proposal with Pierre-Yves, and it is something we want.
Created attachment 316737 [details] [review] Use the system document font instead of system interface font > * Use the system document font by default. Right now, Notes uses the system UI font by default - Cantarell. This is primarily intended for the UI, and not documents. There's a separate document font which would look better. The rest is beyond me at the moment, but this is a tiny fix.
Comment on attachment 316737 [details] [review] Use the system document font instead of system interface font commit c5e18d25620b5500abd94c736a40c012389cbcdc
(In reply to Allan Day from comment #0) > Some assorted font changes that would improve the overall appearance: > > * Use the system document font by default. [...] above commit ; done (thanks Carl!) > > * Increase paragraph spacing. [...] This should be done using css. > * Use the same line and paragraph spacing in the note thumbnails, as in the > notes themselves. [...] This would be done using cairo ; not sure about difficulty level.
Created attachment 316895 [details] Add inter-div spacing, reduce line-height (In reply to Pierre-Yves Luyten from comment #4) > (In reply to Allan Day from comment #0) > > Some assorted font changes that would improve the overall appearance: > > > > * Increase paragraph spacing. [...] > > This should be done using css. I notice that <p> elements aren't inserted, but just setting `margin-top` and `margin-bottom` on the wrapper <div>s added by `e_editor_selection_wrap_lines` and reducing the line height from 2 to 1.5 em seems to improve display considerably -- see following screenshot.
Created attachment 316896 [details] Screenshot of note with <ul> and <ol>, after the above patch Based on "The Elements of Typographic Style Applied to the Web", specifically "Choose a basic leading that suits the typeface, text and measure"[0] -- `line-height: 1.5em` and `margin: .75em` (was .5, corrected in following patch). [0] http://webtypography.net/2.2.1 (I can highly recommend the recipe too ;) )
Created attachment 316897 [details] [review] Add inter-div spacing, reduce line-height top/bottom margin .5 -> .75 em to be half the line-height.
Comment on attachment 316897 [details] [review] Add inter-div spacing, reduce line-height commit bed6de550b54abbc53be9294c7a853b670aa2b5c
thansk for the css now the remaining part might be challenging it lives under biji_note_obj_get_icon (BijiItem *item, gint scale) inside biji-note-obj.c currently it does draw the whole text without any parsing. I don't know if such method makes possible to improve paragraph. Performance might be a question also.
(In reply to Pierre-Yves Luyten from comment #9) > now the remaining part might be challenging As you say, no markup is currently parsed for previews -- would you like me to create a separate bug report for that (and eventually rendering and caching thumbnails using WebKit, to address the probably-valid performance concern) so this one can be closed?
Thanks for the fixes, Carl and Pierre!
(In reply to Carl van Tonder from comment #10) > (In reply to Pierre-Yves Luyten from comment #9) > > now the remaining part might be challenging > > As you say, no markup is currently parsed for previews -- would you like me > to create a separate bug report for that (and eventually rendering and > caching thumbnails using WebKit, to address the probably-valid performance > concern) so this one can be closed? Yes you can create a distinct one, this deserves it!