First of all let me say that I know the title of this thread is 'Modified Sony home screen'. These detailed notes are relevant only to those using Morkl's modified reader app - not his modified home screen app.

I have assumed no previous knowledge of css (Cascading Style Sheet) or html (HyperText Markup Language), so apologies if this is rather long - try not to let it put you off

In summary, if you want to use the modified reader app to customise your fonts, the configuration file, [READER Drive:]\reader\reader.xml, is used in conjunction with 7 css files, which you create yourself using a simple text editor. You then place the 7 css files in the directory [READER Drive:]\reader\css There are some samples included in Morkl's June downloaded zip file.

I'm going to be using a worked example where all of the 3 default fonts (i.e. serif, sans-serif and monospace) have been customised to:

serif: Charis SIL, a slightly darkened version of the standard free version, kindly posted by JSWolf in post #319 of this thread

Create your 7 custom css files and place them in directory [READER Drive:]\reader\css
The 7 .css filenames are highlighted in blue in the above reader.xml file
The corresponding labels you will see in the T1's select-a-font list are highlighted in red in the above reader.xml file.

The first css file to create is [READER Drive:]\reader\css\default.css, and is where the bulk of your effort goes. Here is the contents of default.css in this worked example.
Also see default.css - explanatory notes below for details of what each line does.

The other 6 css files. These are much faster to create. You need to choose the other 6 fonts you want to appear on your select-a-font list. In each of these 6 css files you only need to include the bits you wish to be different from what is already in default.css. You can choose from the many built-in fonts (as listed in the Wiki) or from any you have copied into [READER Drive:]\reader\fonts
Here are 3 examples:

You want the built-in Amasis serif font to be one of your choices and are happy to use the same margins, line spacing, sans-serif & monospace fonts as previously defined in default.css This could be your Amasis.css file:

You actually prefer to read books with all the body text in a sans-serif font, such as the PRST1 built-in Verdana font.
This could be your Verdana.css file, note that both serif and sans-serif are pointing at the same .otf font file:

The 4 font files (regular, italic, bold, bolditalic) making up the Charis SIL serif family are defined in the first 4 lines
@font-face {font-family: serif; ...}
Note the directory path in the URL, res:///ebook/fonts/../../mnt/sdcard/reader/fonts/
This is the directory you can visibly see as [READER Drive:]\reader\fonts (in Windows parlance) when your T1 is connected

The 4 font files (regular, italic, bold, bolditalic) making up the Frutiger Neue sans-serif family are defined in the next 4 lines
@font-face {font-family: sans-serif; ...}
Note: the directory path in these URLs, res:///ebook/fonts/ is different to the one for Charis. This directory is not visible to the user, it is the T1's internal built-in font directory.
If you are already happy with the T1's existing sans-serif font, omit these 4 @font-face lines.

The 4 font files (regular, italic, bold, bolditalic) making up the Dark Courier monospace family are defined in the next 4 lines
@font-face {font-family: monospace; ...}
and are created just like the Charis ones, i.e. pointing to your visible, manually-copied Dark Courier fonts
As before, if you can't be bothered changing the default monospace font, just omit these 4 lines.

The line @page {...} (optional) can be used if you want to create small white-space margins around each page of your epub. Whether you want these page margins is up to you. If you don't, it is better (IMO), to set all 4 margins to zero, rather than remove the line. This is because applying zero margins here, should neutralise any @page already existing inside a particular epub, which may not be non-zero.

The final line, body, body.book, body.text, body.calibre,...{...} is attempting to use your preferences to override what may already be set in the css file contained in each individual epub. You can be quite creative with this depending on your knowledge of css. For this example I have only included 4 simple lines:

font-family: serif;try to force the epub to use your custom serif font, Charis, for all body text

line-height: 1.2;to set the line-spacing
Adjust the 1.2 up or down to suit your preferences. Note: line-height: 1.2 and line-height: 120% are equivalent.

margin-left: 0; margin-right: 0;try to neutralise any over-large left/right margins that may already be inside an epub. Any non-zero left/right margins in here are added to whatever you might have in the @page{...}
Retail epubs are notorious for specifying margins so large that you are reading your whole book as a 3inch strip down the middle.

text-align: justify;try to force each epub to have a straight edge on both left and right sides
if you prefer a ragged right edge set it to text-align: left
Whichever you choose, it's only going to work some of the time due to the cascading nature of css. It may not be possible to do a simple override, like this, on what is already inside the epub's own css file. Personally, I don't add this line, I choose to do the necessary manual changes inside each individual epub, but not everyone can be bothered. (Can't say I blame them)

Why is there a long comma-separated list of body items in that last line?

body

body.book

body.text

body.calibre

body.calibre1

body.calibre2

body.calibre3

body.calibre4

The answer is that it's an ever-growing list of ways in which each individual epub may have defined its html code. You're trying to cover all eventualities. Still doesn't make sense? Nevermind, include them all, anyway. The first 3 are often found in retail epubs, the last 4, not surprisingly, are often found when the epub has been created by a calibre some_format-to-epub conversion. I could explain further, but as this post is aimed at people with no knowledge of html/css, I won't unless specifically asked.

General notes:

I'm not 100% sure of my facts here... If you are going to customise any fonts you must create all 7 css files and put references to all 7 (default + 6 others) in the reader.xml file.[Edit:Morkl suggests there may be dire consequences if you list less/more than 7. Be warned!]

In the reader.xml file you can list the 6 custom css files in any order you like. This is the order in which they will appear in the PRST1 select-a-font list, after 'Original'.

I believe custom font files on a Sony need to be either TrueType (.ttf) or OpenType (.otf). Find them wherever you'd normally look for free font files, e.g. inside your Operating System directory, internet free font sites. Caveat: Not all font files look as good as you might expect -- trial and error I'm afraid. If you're a font fanatic don't be surprised if it takes many hours (days) to finally complete your perfect list of 7.

Please remember at all times, on a PRST1, all paths, filenames, extensions are case-sensitive, unlike Windows.

On a PRST1, when using the slash in a directory path, its a forward-slash (/) -- unlike Windows where it's a back-slash (\).

However much effort you put into your 7 css files, you will find some epubs which won't use your preferences. In these cases the only way to beat them into submission is to open them up (in Sigil or calibre Tweak ebook) and get your hands dirty in the css file within to remove the bits which are overriding your preferences. This requires some knowledge of html and css. No way round it but to learn a bit or learn to be less picky, I'm afraid -- entirely your choice .

I'm going cross-eyed at this point, so I'm going to call it a day for this first draft. If anyone spots anything which could be explained better, please let me know (politely) and I'll update accordingly.

I have to disagree with the CSS for default. The line-height is not needed at all. Plus, the @page is also no needed and if anyone wants a specific @page, they can add it in with Modify ePub. Also, the widows and orphans set to 0 makes the end of the page much nicer then the constantly shifting end.

Thinking about taking the plunge into installing this fantastic Modified Reader app on an unrooted T1 and I was wondering if this was similar to a firmware update.
IE: Is it good practice to make sure I'm on a fully charged battery when attempting this? Also, should I be bothered with formatting or factory resetting my e-reader first, applying the latest firmware update and then installing this?

@JSWolf,
You are welcome to add your own opinions, but neither yours nor mine are the 'One True Way'. But taking your points one at a time:

I included a line-height merely as an illustrative option of what you can use if you feel like it, along with an example of how to supercede it when using a different font. In addition, the case for including it is that it is a good way of (trying) to override an unwanted line-height value which may already be in an epub's internal css file. Retail epubs often set a line-height in their body{...} css.

Similarly, I listed the @page{...} as optional. It's a way (I think) of
a) not needing to add margins to every single epub using calibre
b) overriding page margins in calibre epubs, that you wish you'd never put in, in the first place.
Putting the @page{} in here should override any already in the epub. I think I need to test that rash statement tomorrow.Edit: Did some testing. I'm sticking to my original reasoning.

Adding margin-left: 0; margin-right: 0 in the body{...} css. I'll concede that one and add it to the original post. It's a good way to try and neutralise the ludicrous left/right margins, publishers put in retail epubs. I missed it because it's one of the things I obsessively edit manually in every epub.

Adding margin-top: 0; margin-bottom: 0; to the body{...} css. This may suit you (and probably many others) but it wouldn't suit everyone, me for one. I like a bit of space between some types of paragraphs and a lot of space between other types e.g. scenebreaks. Include it if you want, but it's one of the things that is difficult to achieve your 'perfect' result unless you manually selectively edit parts of every epub.

With retail epubs which have DRM still in place and which include their own embedded fonts, you have a better chance of overriding with your custom font choice if you put the font-family: serif in a body{...} statement, as per my example, rather than the html{...} statement, as per your example.
However, some people may like to use the publisher's embedded font in these special circumstances. In which case, your way is better. Although, since most (95%+ ?) retail epubs which do embed fonts, embed the standard Charis font rather than your superior darkened version (did I really just say that ) why would I ever want to use the embedded font.

Re: widows and orphans... I deliberately didn't include these for 2 reasons. Firstly, this was meant to be a primer and not everyone knows (or cares) what widows and orphans are. Secondly, and more important, I have tried to use them on the PRST1 and couldn't get them to work. I frequently saw multi-line paragraphs which had the first line on one page and the rest of the paragraph on the next page - which I thought those settings were supposed to stop. I also saw the converse, namely all but the last line of a paragraph on one page and its last line on the next page.[Edit: for anyone who cares strongly about widows and orphans. After further testing, you can try to override any epub internal css by editing the body{...} statement of default.css as follows:

Doing nothing at all should be equivalent to (a), unless the epub creator has specified otherwise in the epub's internal css.

As for repeating all css code in all css files. You can choose to do it this way if you prefer, but I'm an old-school programmer type. If I have to hard-code anything, I do it in the minimum of places so that when I want to change it I only have to do it once. It's purely a personal choice and everyone should do what they are most comfortable with.

Lastly, people who are new to all this may not want to get into the finer points of using calibre's 'Modify Epub' plugin (which would also require learning about DRM removal beforehand) . I'm trying to suggest a default.css file which can customise as many epubs as possible without having to learn much about css, and nothing at all about DRM removal and calibre plugins. [Added: calibre's Modify Epub plugin is an excellent tool, for those who wish to dig a bit deeper.]

BTW, I'm happy to further debate Sony vs. css best practice with you, if you like, but this thread is not the place to do it. PM me any time you like. Might be fun

Thinking about taking the plunge into installing this fantastic Modified Reader app on an unrooted T1 and I was wondering if this was similar to a firmware update.

Similar, but quicker and doesn't change so much of the internals.

Quote:

Originally Posted by WarGhSt

Is it good practice to make sure I'm on a fully charged battery when attempting this?

Not absolutely sure. I did to be on the safe side. What harm can it do?

Quote:

Originally Posted by WarGhSt

Also, should I be bothered with formatting or factory resetting my e-reader first

Don't think so. I didn't.

Quote:

Originally Posted by WarGhSt

...should I be bothered with applying the latest firmware update and then installing this?

Definitely. Your first step before applying this modified reader app is to make sure your PRST1 already has the latest Sony official firmware, version 1.0.04.12210. Follow all precautions as detailed by Sony in their official firmware upgrade instructions.

... widows and orphans set to 0 makes the end of the page much nicer then the constantly shifting end.

Quote:

Originally Posted by jackie_w

[*]Re: widows and orphans... I have tried to use them on the PRST1 and couldn't get them to work. I frequently saw multi-line paragraphs which had the first line on one page and the rest of the paragraph on the next page - which I thought those settings were supposed to stop. I also saw the converse, namely all but the last line of a paragraph on one page and its last line on the next page.

I apologize for getting even further off topic, but I'm intrigued by this widows and orphans thing. I've never used it in any of my CSS, but I regularly have ebooks that will have all but the last line or two of a paragraph on one page with its last line or two on the next page. Is this because the publisher is using widows/orphans or is it because they're not?

I apologize for getting even further off topic, but I'm intrigued by this widows and orphans thing. I've never used it in any of my CSS, but I regularly have ebooks that will have all but the last line or two of a paragraph on one page with its last line or two on the next page. Is this because the publisher is using widows/orphans or is it because they're not?

It's because ADE defaults to a widows & orphans value of 2. Setting them to 0 overrides that.

@JSWolf,
You are welcome to add your own opinions, but neither yours nor mine are the 'One True Way'. But taking your points one at a time:

I included a line-height merely as an illustrative option of what you can use if you feel like it, along with an example of how to supercede it when using a different font. In addition, the case for including it is that it is a good way of (trying) to override an unwanted line-height value which may already be in an epub's internal css file. Retail epubs often set a line-height in their body{...} css.

I find a lot of publishers use a line height of 1.2 and to me, that's too large. For a sample, I suggest a smaller value that would be good for those who want more of a lace between the lines, but not that big.

Quote:

Similarly, I listed the @page{...} as optional. It's a way (I think) of
a) not needing to add margins to every single epub using calibre
b) overriding page margins in calibre epubs, that you wish you'd never put in, in the first place.
Putting the @page{} in here should override any already in the epub. I think I need to test that rash statement tomorrow.

I would not put @page in the CSS here. It's fixed that way and there's nothing you can do about it. If it does override what might be in the ePub's CSS then that is the only @page you get for every ePub. I would suggest setting the margins in Calibre and using the Modify ePub plugin to add in the @page. That way, you can change it if you want very easily or remove it if that's what's you want.

Quote:

Adding margin-left: 0; margin-right: 0 in the body{...} css. I'll concede that one and add it to the original post. It's a good way to try and neutralise the ludicrous left/right margins, publishers put in retail epubs. I missed it because it's one of the things I obsessively edit manually in every epub.

I find that the way the bezel of the Sony readers is made, that having a margin of 0 is not a problem. One way to deal with the silly overly large margins in ePub is again to use the Modify ePub plugin. Sometimes that silly margin is set in the page template file and Modify ePub can easily and quickly get rid of it.

Quote:

Adding margin-top: 0; margin-bottom: 0; to the body{...} css. This may suit you (and probably many others) but it wouldn't suit everyone, me for one. I like a bit of space between some types of paragraphs and a lot of space between other types e.g. scenebreaks. Include it if you want, but it's one of the things that is difficult to achieve your 'perfect' result unless you manually selectively edit parts of every epub.

I mostly agree here. I do set a space of 2em for scene break space and yes, there should be some space between certain types of paragraphs. But the majority of paragraphs don't need space between them. But for example, when something is centered, a space of .5em top/bottom

Quote:

With retail epubs which have DRM still in place and which include their own embedded fonts, you have a better chance of overriding with your custom font choice if you put the font-family: serif in a body{...} statement, as per my example, rather than the html{...} statement, as per your example.
However, some people may like to use the publisher's embedded font in these special circumstances. In which case, your way is better. Although, since most (95%+ ?) retail epubs which do embed fonts, embed the standard Charis font rather than your superior darkened version (did I really just say that ) why would I ever want to use the embedded font.

Do you have a solution on how to get the publisher font to work in case the eBook has fonts you do want to see doing it your way?

Quote:

Re: widows and orphans... I deliberately didn't include these for 2 reasons. Firstly, this was meant to be a primer and not everyone knows what widows and orphans are. Secondly, and more important, I have tried to use them on the PRST1 and couldn't get them to work. I frequently saw multi-line paragraphs which had the first line on one page and the rest of the paragraph on the next page - which I thought those settings were supposed to stop. I also saw the converse, namely all but the last line of a paragraph on one page and its last line on the next page.

I put them in as a matter of course because I don't like the end of the page changing. I don't mind single lines from a given paragraph at the top/bottom of the page.

Quote:

As for repeating all css code in all css files. You can choose to do it this way if you prefer, but I'm an old-school programmer type. If I have to hard-code anything, I do it in the minimum of places so that when I want to change it I only have to do it once. It's purely a personal choice and everyone should do what they are most comfortable with.

I figure if it's good for the default, it's good for all fonts except maybe a specific font size to start with.

Quote:

Lastly, people who are new to all this may not want to get into the finer points of using calibre's 'Modify Epub' plugin (which would also require learning about DRM removal beforehand) . I'm trying to suggest a default.css file which can customise as many epubs as possible without having to learn much about css, and nothing at all about DRM removal and calibre plugins.

I suggest Modify ePub as well. It's one very nice pugin that eliminates having to do a lot of things manually that I used to do.

Quote:

BTW, I'm happy to further debate Sony vs. css best practice with you, if you like, but this thread is not the place to do it. PM me any time you like. Might be fun

Or we could start a new thread just on the modified reader and separate it from the home screen.