ADE reversing pages? - Page 2

BetterRed · 03-26-2017, 06:02 PM

@HarryT

I originally wrote '. . . various Afroasiatic languages and dialects . . .'.

Of which Coptic is one, but so too are the Semitic languages - including Arabic and Hebrew. So I was in a dilemma, a Catch 22

I'd quite like to see a snippet where Arabic is used in the book's text along with a chapter number. I could have missed it when I flicked though the book.

Maybe there's a reference to the Scheherazade (Rimsky-Korsakov) libretto, that got translated to Arabic. But its almost always performed as a ballet.

I should read the book, but its a long way down the pile

BR

Hitch · 04-02-2017, 07:26 PM

Quote:

Originally Posted by ChipSuey

I was able to attach the content.opf file, but I can't seem to upload the css or xhtml file, so I'm posting them as text here (snippets)

Chapter 8 (since that was the example I gave before)

<?xml version='1.0' encoding='utf-8'?>
<html xmlns="http://www.w3.org/1999/xhtml"><head>
<title>The Other La Bohème</title>

<link href="../stylesheet.css" rel="stylesheet" type="text/css"/>
<link href="../page_styles.css" rel="stylesheet" type="text/css"/>
</head>
<body id="AAN1104_Digest-11" lang="en-US" class="calibre">
<div class="_idgenobjectstyleoverride1">
Scene 8
<img class="_idgenobjectattribute3" src="image/16.png" alt=""/>
On a Friday John a quiet corner.

and the stylesheet.css (this one's pretty long)

<snipped>

Driving me nuts, this is!

One other comment, which you'll probably ignore, but: if someone at my shop handed me that CSS, for a book we were doing, he wouldn't be working for me the following day. That's not "clean." Not even remotely. You said it had been cleaned--whoever is doing that clean-up for you--you need to have a chat with that person. I have no objection to large CSS sheets; we use one ourselves, in our "HouseCSS." But we typically delete everything we're not using, so that forensics, if we have issues, and troubleshooting, are expedited, not hindered.

I tell you this not to criticize, but whatever is being used to clean it, isn't doing the job. Troubleshooting in this horrifically messy environment is 10x the difficulty as it should be. Delete all the utterly unnecessary margin calls, at LEAST. I assume that the blank chunks are you disguising something you don't want us to see--if they aren't, delete those, too.

TONS of stuff here that should be deleted. I'd also remark that except in unique situations, I wouldn't be sizing things in px. That's asking for trouble.

Offered solely FWIW.

Hitch

JSWolf · 04-04-2017, 05:59 AM

That CSS is very sloppy. It's not been cleaned. Also, the fonts used for embedding, remove them unless you need them. Minion Pro is a dreadful font on eInk. Don't make people suffer with it. I don't know the sans-serif font you've chosen, but dump that too and just use sans-serif as the font and let the default sans serif font be used. When you dump Minion Pro, also dump the entire font-family line. Do not leave in any font-family: serif.

If you are using that CSS as a house CSS, it needs to be cleaned up before being used and all the unused styles need to go for each book.

blackest · 04-15-2017, 06:30 AM

Quote:

Originally Posted by DiapDealer

I understand that some books may contain multi-language content, but can someone explain what is gained (or hoped to be gained) by putting a dc:language entry in the OPF for each language that appears in the book, rather than just the single primary language entry?

If dictionary look-ups are what the eventual goal is, I was under the impression that was better achieved by adding spans around different language sections in the (x)html with the proper "lang" attribute defined.

I earlier moved arabic from the first language to the last which solved the issue for ade but importing into ibooks the the layout is right to left with arabic being placed last

for me the solution was to delete the language but a more general solution is to use a single language at this level which renders as you intend. Since ade uses the first language and ibooks the last. The simplest solution is to make first and last one and the same

With the general rule being that the styling nearest the text wins I think Apple are most likely correct in their interpretation. On a practical basis Ade's implementation is likely to be most common.

So far the only system that comes close to listening to the css styling rules is google playbooks.

DiapDealer · 04-15-2017, 08:26 AM

So what I'm hearing is that in ALL cases, a single opf dc language entry (representing the book's primary language) is what is guaranteed to work properly everywhere (which does not surprise me in the least).

What I'm not hearing, is why multiple dc language entries are being added to the opf in the first place. I see no advantage in doing so. In fact doing so can only cause problems--as this thread proves.

So where does the ill-advised practice of multiple opf dc language entries originate from? Anybody?

blackest · 04-15-2017, 01:55 PM

Quote:

Originally Posted by DiapDealer

So what I'm hearing is that in ALL cases, a single opf dc language entry (representing the book's primary language) is what is guaranteed to work properly everywhere (which does not surprise me in the least).

What I'm not hearing, is why multiple dc language entries are being added to the opf in the first place. I see no advantage in doing so. In fact doing so can only cause problems--as this thread proves.

So where does the ill-advised practice of multiple opf dc language entries originate from? Anybody?

Well I'm redoing a book for a friend which was published as a fixed layout epub3 and a pdf version. For the meta data for the book I lifted it straight from the fixed layout version, which as far as I know was generated using indesign.

I don't know if indesign generated the meta data or the publisher used a standard template.

I can't track it down unfortunately. I think indesign uses javascript to add metadata maybe a bad script??

DiapDealer · 04-15-2017, 02:36 PM

Wouldn't be the first time InDesign was guilty of introducing problems.

Thanks for the input. I've purchased many epubs (both version 2 and version 3) over the years, but I've never purchased one from a commercial source that had more than one dc language entry in the opf's metadata section. This thread is the first place I've ever heard talk of it, in fact.

EDIT: the latest EPUB specifications state that more than one language element MAY be included for multi-language documents, but it doesn't explain what the advantages would be (nor how reading systems are expected to address multiple language elements). So as usual, everyone makes up their own rules as to how multiples are prioritized.

blackest · 04-15-2017, 09:48 PM

Quote:

Originally Posted by DiapDealer

Wouldn't be the first time InDesign was guilty of introducing problems.

Thanks for the input. I've purchased many epubs (both version 2 and version 3) over the years, but I've never purchased one from a commercial source that had more than one dc language entry in the opf's metadata section. This thread is the first place I've ever heard talk of it, in fact.

EDIT: the latest EPUB specifications state that more than one language element MAY be included for multi-language documents, but it doesn't explain what the advantages would be (nor how reading systems are expected to address multiple language elements). So as usual, everyone makes up their own rules as to how multiples are prioritized.

You did better than me all i could find was references to the standard codes to be used but not a single why. Just a every document needs a language specified

actually identifier, language and title, are compulsory it would be nice if they defined how they are meant to be used ...

BetterRed · 04-15-2017, 10:17 PM

Quote:

Originally Posted by DiapDealer

EDIT: the latest EPUB specifications state that more than one language element MAY be included for multi-language documents, but it doesn't explain what the advantages would be (nor how reading systems are expected to address multiple language elements). So as usual, everyone makes up their own rules as to how multiples are prioritized.

Tagging passages/fragments in foreign languages is a PITA, especially if more than one f-l. So maybe -- if a dictionary lookup on a word using the first language doesn't yield a result, try the second language... or on a dictionary lookup, show the results for each language... or do nothing

BR

Tex2002ans · 04-16-2017, 01:48 AM

Quote:

Originally Posted by DiapDealer

What I'm not hearing, is why multiple dc language entries are being added to the opf in the first place. I see no advantage in doing so. In fact doing so can only cause problems--as this thread proves.

So where does the ill-advised practice of multiple opf dc language entries originate from? Anybody?

I would say it is/was just years of poor practices.

Maybe it was borne from poor usage of the HTML meta element for years:

https://www.w3.org/International/que...-http-and-lang

Quote:

Specifying language with the meta element (not recommended)

The use of a meta element in the document head with the http-equiv attribute set to Content-Language is not mentioned directly in the HTML 4.01 specification, and yet, for a long time, much of the informal guidance out on the Web about how to declare language for your HTML page suggested its use, and some HTML authoring tools automatically created such elements when you specified language information using dialog boxes. Here is an example that declares the language to be English.

***Do not use this*** <meta http-equiv="Content-Language" content="en">

Unlike the lang and xml:lang attributes, the value of the content attribute can be a comma-separated list of language tags. The example below declares the primary languages of the document to be (in equal measure) German, French and Italian.

***Do not use this*** <meta http-equiv="Content-Language" content="de, fr, it">

If the name of the meta element wasn't a clear enough clue, the fact that the value supports multiple languages indicates that this element is really about document level metadata. If you are to usefully indicate the language of a range of text, you have to be specific – it can only be in one language at a time. The meta element, then, is an in-document location for expressing metadata about the language of the intended audience of the document as a whole.

[...]

Because of the history of confusion and inconsistent implementation surrounding this kind of declaration, in 2011 the HTML Working Group took a decision to make the meta element with http-equiv set to Content-Language non-conforming in HTML. This means that you should no longer use it in HTML5, and therefore, though technically not illegal in other types of HTML, it is best to now not use it anywhere.

Perhaps InDesign already had their non-standard HTML meta output... and then Adobe just decided to convert that HTML meta directly to dc:language in EPUBs?

Speaking of multiple dc:language in EPUBs, this mention of Dublin Core was slightly further down the page:

Quote:

[...]

Dublin Core on the meta element. Since the rules in HTML4 for meta elements put few restrictions on how it is used, it is also possible, though not common, to find instances where it is used to express language information using Dublin Core notation. It does not appear, however, that this information is ever used by browsers, and it is unclear to what extent it is used by any other application.

Maybe it was just have been a simple carryover from the OEBPS days (1999-2007).

Or maybe when the EPUB standard was being put together they just decided, "Sure, a lot of the cool hip kids are still doing it in HTML nowadays."

Quote:

Originally Posted by BetterRed

Tagging passages/fragments in foreign languages is a PITA, especially if more than one f-l. So maybe -- if a dictionary lookup on a word using the first language doesn't yield a result, try the second language... or on a dictionary lookup, show the results for each language... or do nothing

In the case of a book, I would say you could MAYBE stick two languages in your content.opf if you had a Left/Right English/German translation (although know this could be buggy as ChipSuey found out).

But besides that specific use-case, only have one overarching main language + mark the foreign text directly with lang + xml:lang. This would be the least buggy option in all the readers, and be much closer to its actual intended use on the text processing side of things (search/dictionary/text-to-speech/[...]).

This is the relevant text from the w3 link linked above:

Quote:

Specifying file metadata: the language of the intended audience

Metadata that describes the language or languages of the intended audience is about the document as a whole. Such metadata may be used for searching, serving the right language version, workflow management, classification, etc. Where there are language changes in a document, information about the language of the intended audience is not specific enough to support text-processing (for example in a way that would be needed for the application of text-to-speech, styling, automatic font assignment, etc.)

The language of the intended audience does not include every language used in a document. Many documents on the Web contain embedded fragments of content in different languages, whereas the page is clearly aimed at speakers of one particular language. For example, a German city-guide for Beijing may contain useful phrases in Chinese, but it is aimed at a German-speaking audience, not a Chinese one.

On the other hand, it is also possible for a page to contain the same or parallel content in more than one language. For example, a Canadian web page may welcome readers with French content in the left column, and the same content in English in the right-hand column. Here the document is equally targeted at speakers of both languages, so there are two audience languages. This situation is not as common on the Web as in printed material since it is easy to link to separate pages on the Web for different audiences, but it does occur where there are multilingual communities. Another use case is a blog or a news page aimed at a multilingual community, where some articles on a page are in one language and some in another. For example, a forum used by a Punjabi community may contain posts in English, Hindi and Punjabi in a single thread.

There are also pages where the navigational information, including the page title, is in one language but the real content of the page is in another. While this is not necessarily good practice, it doesn't change the fact that the language of the intended audience is usually that of the content, regardless of the language at the top of the document source.

Having four or five dc:languages in a book though? That just sounds absolutely out of intended scope of "the language of the document as a whole".

04-04-2017, 05:59 AM	#18
JSWolf Resident Curmudgeon Posts: 73,845 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	That CSS is very sloppy. It's not been cleaned. Also, the fonts used for embedding, remove them unless you need them. Minion Pro is a dreadful font on eInk. Don't make people suffer with it. I don't know the sans-serif font you've chosen, but dump that too and just use sans-serif as the font and let the default sans serif font be used. When you dump Minion Pro, also dump the entire font-family line. Do not leave in any font-family: serif. If you are using that CSS as a house CSS, it needs to be cleaned up before being used and all the unused styles need to go for each book. Last edited by JSWolf; 04-04-2017 at 06:02 AM.

04-15-2017, 02:36 PM	#22
DiapDealer Grand Sorcerer Posts: 27,539 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	Wouldn't be the first time InDesign was guilty of introducing problems. Thanks for the input. I've purchased many epubs (both version 2 and version 3) over the years, but I've never purchased one from a commercial source that had more than one dc language entry in the opf's metadata section. This thread is the first place I've ever heard talk of it, in fact. EDIT: the latest EPUB specifications state that more than one language element MAY be included for multi-language documents, but it doesn't explain what the advantages would be (nor how reading systems are expected to address multiple language elements). So as usual, everyone makes up their own rules as to how multiples are prioritized. Last edited by DiapDealer; 04-15-2017 at 02:52 PM.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Humor Ade, George: Ade's Fables. v1. 24 Aug 2015	crutledge	ePub Books	0	08-24-2015 07:43 AM
Humor Ade, George: Ade's Fables. v1. 24 Aug 2015	crutledge	BBeB/LRF Books	0	08-24-2015 07:41 AM
ADE adds blank pages?	Psymon	ePub	84	09-28-2014 11:41 AM
Safely reversing some changes K4NT	mental2k	Kindle Developer's Corner	2	06-26-2013 07:48 AM
Reversing articles order in a custom news recipe?	mairabc	Calibre	5	12-12-2009 05:24 PM

03-26-2017, 06:02 PM	#16
BetterRed null operator (he/him) Posts: 20,532 Karma: 26944418 Join Date: Mar 2012 Location: Sydney Australia Device: none	@HarryT I originally wrote '. . . various Afroasiatic languages and dialects . . .'. Of which Coptic is one, but so too are the Semitic languages - including Arabic and Hebrew. So I was in a dilemma, a Catch 22 I'd quite like to see a snippet where Arabic is used in the book's text along with a chapter number. I could have missed it when I flicked though the book. Maybe there's a reference to the Scheherazade (Rimsky-Korsakov) libretto, that got translated to Arabic. But its almost always performed as a ballet. I should read the book, but its a long way down the pile BR

04-15-2017, 08:26 AM	#20
DiapDealer Grand Sorcerer Posts: 27,539 Karma: 193191846 Join Date: Jan 2010 Device: Nexus 7, Kindle Fire HD	So what I'm hearing is that in ALL cases, a single opf dc language entry (representing the book's primary language) is what is guaranteed to work properly everywhere (which does not surprise me in the least). What I'm not hearing, is why multiple dc language entries are being added to the opf in the first place. I see no advantage in doing so. In fact doing so can only cause problems--as this thread proves. So where does the ill-advised practice of multiple opf dc language entries originate from? Anybody?