Controlling wraps in epubs

Iznogood · 10-30-2011, 08:03 AM

Hi

I'm currently working on converting some of my old books by Quentin Patrick to epub, and have run into a situation where I need to control where wrapping of words will happen. One of the characters in the book is spelling a name, and this is indicated with a dash (-) between each letter in the name, like this: S-a-n-t-a-i-s. However, readers will interprit the dash as a good place to add a line-break, whilst I, on the other hand, does not want that word to wrap to a new line in the middle of the name.

I have tried "white-space:nowrap;", which seems promising, but gives me one problem: if the screen is too small or the font is too big to fit the entire name on one line, I obviously want the word to break to a new line. Not because it is correct to break there, but because it is neccessary to view the entire name. With the white-space CSS property, the part of the name that does not fit the screen vanishes.

I have also experimented with "display:inline-block", which was suggested by Liz Castro in one of her blogs. This option gives me problems with the various readers adding various margins to the left and right of the block, and I can't find a way to make that word look the same on all readers I have access to (an calibre, sigil and an ipad with ibooks, stanza and bluefire).

Anyone "out there" who have found a solution to this? I know that no reader will render css the same way, and I realize that there are no guarantee of achieving correct result on all readers, but I would like to try.

Iznogood · 10-30-2011, 07:32 PM

Update: as a workaround I tried using non-breaking hypens (html & #8209; ), and it seems to solve my problem. From my understanding, this character will not be rendered as a hypen, but as any other character. This in turn requires that the reader has this character embedded in the font it's using.

I've had problems with these special characters not displaying properly before, and was wondering if any of you have had problems with this character, or if it's "safe" to use?

JohnnyNonsense · 10-31-2011, 12:38 AM

When a hyphen is used in place of a dash, it is typically surrounded by spaces. So, you could try using non-breaking spaces:
S - a - n - t - a - i - s
You could try using ragged-right justification on the containing paragraph, if you haven't already.

Jellby · 10-31-2011, 04:58 AM

A non-breaking hyphen is what you want. If it's not supported by the default reader font, that's not your problem (besides, the rendering software should be smart enough to use a normal hyphen if the specific character is not found). But actually, is it so grave if the word is split at line end? That's probably better than the additional word space that would result if the whole bit is moved to the next line.

You could also try a non-breaking zero-width space (word joiner), & #8288;, after each hyphen, but you'll probably be in the same situation if the font has no definition for it.

Iznogood · 11-01-2011, 11:54 AM

Quote:

Originally Posted by JohnnyNonsense

you could try using non-breaking spaces:
S - a - n - t - a - i - s
You could try using ragged-right justification on the containing paragraph, if you haven't already.

Thanks for the tip. The non-breaking space worked, but I don't think I will be using it for this project since there are no spaces in the paper book, and I try to be as faithful to the source as possible. the ragged-right justification didn't alter anything though. Have I misunderstood something, or isn't ragged-right justification the same as plain ol' left justification?

Quote:

Originally Posted by Jellby

A non-breaking hyphen is what you want. If it's not supported by the default reader font, that's not your problem (...) But actually, is it so grave if the word is split at line end? That's probably better than the additional word space that would result if the whole bit is moved to the next line.

You could also try a non-breaking zero-width space (word joiner), & #8288;, after each hyphen, but you'll probably be in the same situation if the font has no definition for it.

The zero-width space sounds scary, especially since most of my project using special characters like thinspace and equal has ended up with the reader not being able to render the content properly. So the less I have of these, the more happy I am. I will go for the non-breaking hypen then, and hope it renders properly.

Of course I would not take my death of it if I had to cope with linebreak in the middle of this sequence of letters, but I find it looks more pleasing it I can keep it on one line, even though there will probably by, as you pointed out, more white spece on the line when the entire sequence is shifted to the next line

10-30-2011, 08:03 AM	#1
Iznogood Guru Posts: 932 Karma: 15752887 Join Date: Mar 2011 Location: Norway Device: Ipad, kindle paperwhite	Controlling wraps in epubs Hi I'm currently working on converting some of my old books by Quentin Patrick to epub, and have run into a situation where I need to control where wrapping of words will happen. One of the characters in the book is spelling a name, and this is indicated with a dash (-) between each letter in the name, like this: S-a-n-t-a-i-s. However, readers will interprit the dash as a good place to add a line-break, whilst I, on the other hand, does not want that word to wrap to a new line in the middle of the name. I have tried "white-space:nowrap;", which seems promising, but gives me one problem: if the screen is too small or the font is too big to fit the entire name on one line, I obviously want the word to break to a new line. Not because it is correct to break there, but because it is neccessary to view the entire name. With the white-space CSS property, the part of the name that does not fit the screen vanishes. I have also experimented with "display:inline-block", which was suggested by Liz Castro in one of her blogs. This option gives me problems with the various readers adding various margins to the left and right of the block, and I can't find a way to make that word look the same on all readers I have access to (an calibre, sigil and an ipad with ibooks, stanza and bluefire). Anyone "out there" who have found a solution to this? I know that no reader will render css the same way, and I realize that there are no guarantee of achieving correct result on all readers, but I would like to try.

10-30-2011, 07:32 PM	#2
Iznogood Guru Posts: 932 Karma: 15752887 Join Date: Mar 2011 Location: Norway Device: Ipad, kindle paperwhite	Update: as a workaround I tried using non-breaking hypens (html & #8209; ), and it seems to solve my problem. From my understanding, this character will not be rendered as a hypen, but as any other character. This in turn requires that the reader has this character embedded in the font it's using. I've had problems with these special characters not displaying properly before, and was wondering if any of you have had problems with this character, or if it's "safe" to use? Last edited by Iznogood; 10-30-2011 at 07:34 PM. Reason: Typo

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Calibre re-wraps poetry	PhotoMatt	Conversion	6	03-03-2011 08:45 AM
Convert TXT to anything - simply wraps with < html > < body > ?	jmurphy	Calibre	7	08-06-2009 06:50 AM
Controlling Calibre's Splits for epubs.	brewt	Calibre	4	12-31-2008 03:10 PM
Digitimes wraps up electronic paper	TadW	News	1	07-21-2007 09:35 AM

10-31-2011, 12:38 AM	#3
JohnnyNonsense Junior Member Posts: 4 Karma: 10 Join Date: Oct 2010 Device: none	When a hyphen is used in place of a dash, it is typically surrounded by spaces. So, you could try using non-breaking spaces: S - a - n - t - a - i - s You could try using ragged-right justification on the containing paragraph, if you haven't already.

10-31-2011, 04:58 AM	#4
Jellby frumious Bandersnatch Posts: 7,516 Karma: 18512745 Join Date: Jan 2008 Location: Spaniard in Sweden Device: Cybook Orizon, Kobo Aura	A non-breaking hyphen is what you want. If it's not supported by the default reader font, that's not your problem (besides, the rendering software should be smart enough to use a normal hyphen if the specific character is not found). But actually, is it so grave if the word is split at line end? That's probably better than the additional word space that would result if the whole bit is moved to the next line. You could also try a non-breaking zero-width space (word joiner), & #8288;, after each hyphen, but you'll probably be in the same situation if the font has no definition for it.

Advert

Advert