search

nlbdev / pipeline

NLB branch of the super-project that aggregates all Pipeline related code. See https://github.com/daisy/pipeline for the main branch.
http://repo.nlb.no/pipeline
3 stars 1 forks source link

Correct numbering of pages #78

Closed matskober closed 6 years ago

matskober commented 7 years ago

Seem to me that are some overlapping issues regarding braille page numbers. (#59 and #56 are two; but I wrote a comment some place else, also)

I suggest that we skip the rule saying that braille page numbers are to start at the books main content ("bodymatter" in DTBook terminology), and starts counting at the front page. Then we can show or hide the braille page number on the various kinds of pages using css.

It will also give consistency between the braille page number appearing in the book and the total page number of the production. @bertfrees @josteinaj @KariRudjord @usama49

josteinaj commented 7 years ago

Ok. Should it start at 1 at the beginning of each volume?

KariRudjord commented 7 years ago

I agree, @matskober (but not counting from 1 at the beginning of each volume, @josteinaj )

josteinaj commented 7 years ago

@KariRudjord Ok. On Slack you mentioned that the frontpage and first left page should not be counted?

KariRudjord commented 7 years ago

@josteinaj Counted but hidden with CSS, so the pagenum is not present on the title page and the first left page, as Mats suggested

josteinaj commented 7 years ago

Ok.

bertfrees commented 7 years ago

I'm afraid this is not possible at the moment: see https://github.com/brailleapps/dotify/issues/165

matskober commented 7 years ago

If it's not possible to include generated content, I suggest we start the braille counting on the first not-generated element in the book.

bertfrees commented 7 years ago

This is how we do it now, except the page numbers are hidden on the first pages of the volume, right?

matskober commented 7 years ago

No, here it starts at page 0 - and it is a introduction chapter,or something, from the frontmatter of the DTBook, that is without any braille page number. results (2).zip

bertfrees commented 7 years ago

That introduction chapter from the DTBook frontmatter is indeed added to the frontmatter of the volume. This was probably done to get the current page numbering behavior. It could be added to the volume bodymatter instead, that's not a problem.

I don't see any page 0 anymore in your example. I thought I fixed that (https://github.com/nlbdev/pipeline/issues/56).

matskober commented 7 years ago

page 0 seems to be gone, yes :)

josteinaj commented 7 years ago

@matskober so does page numbering work in a good (or at least acceptable) way now?

bertfrees commented 7 years ago

I have not implemented what Mats suggested above yet.

If it's not possible to include generated content, I suggest we start the braille counting on the first not-generated element in the book.

matskober commented 7 years ago

results (4).zip The id="level1_3" in frontmatter is missing braille page number

josteinaj commented 7 years ago

Moving comment from duplicate issue #90 here:

from @matskober:

bodymatter, body:not([epub|type~='cover']):not([epub|type~='frontmatter']):not([epub|type~='backmatter']) {
       page: body;
       counter-set: page 1;
}

@usama49 : Could you look in to this?

The braille page number now starts counting 1 at the front page of each volume (this is not as it should be.), and at 1 on the first element in the DTBook's bodymatter (this counting runs thru out all volumes - only the generated pages in the beginning of each volume - as it shall).

The braille page number 1 should appear at the bottom of the first non-generated page in the first volume, regardless of whether this element is in the front or bodymatter of the DTBook. e.g. should a preface have braille pagination.

The generated pages are not to have any page numbers!

bertfrees commented 7 years ago

So, to summarize, the desired behavior is:

However, with the current state of Dotify this can not be achieved. All content that is repeated in every volume (.pef-titlepage, #generated-toc) is completely separated from the main flow and therefore also has its own numbering. The same is true for endnotes at the end of a volume. In addition, because of the way the .notes-placement and .notes-placement-fallback fields are currently implemented, .pef-about can not be part of the main flow either.

Endnotes pages at the end of the book can be part of the main flow, however for consistency it's better to treat them the same as endnotes pages at the end of volumes.

So for the time being we decided to do the following:

The fact that the number of pages as displayed in the about section will not match the page number of the last page in the book is not a problem.

bertfrees commented 7 years ago

Implemented as described above.

matskober commented 6 years ago

see job#1229 Pagenumber on toc in first volume Starts new counting of pagenumber at first non-generated element @bertfrees @josteinaj

bertfrees commented 6 years ago

Pagenumber on toc in first volume

OK I see already what the problem is. The rule below should be added. Forgot to add it when I rebased my page numbering fixes onto Jostein's TOC fixes.

#generated-document-toc {
        page: auto;
}

Starts new counting of pagenumber at first non-generated element

This is expected behavior, right? (see https://github.com/nlbdev/pipeline/issues/78#issuecomment-336142141)

bertfrees commented 6 years ago

The initially desired behavior, namely:

could now in theory be implemented, but it'll require some work. I'll have to:

KariRudjord commented 6 years ago

What do you think of this, @josteinaj ?

The reason I want it, is that I want a simple way to get total amount of pages in a book (including all) to put into our library system and for the publisher. Preferably in an automatic way. (Today we open every book in the Easy utility embosser, go to last page of last volume and write down the number manually).

Is there an easier way to get the total amount of pages (and volumes) or should Bert start the work described above?

josteinaj commented 6 years ago

I think this would be a nice feature to have, so yes.

Also, keeping up to date with the latest dotify seems like a good idea in itself.

The temporary solution is good enough for us to use in production though, so I don't this should be a high priority any more.

bertfrees commented 6 years ago

My 2 cents: don't change the layout just as a way of obtaining the total number of pages to put in a database. Do what is best from a end user perspective. If it's just for getting the number of pages, I think it's better to use metadata. Then it could even be made automatic. The total number of pages including everything should be really easy to compute based on the PEF in a post-processing step. For more advanced metadata we can query Dotify (see also https://github.com/brailleapps/dotify.api/issues/14).

josteinaj commented 6 years ago

Yes, I agree.

@KariRudjord if you don't have to worry about exporting the total number of pages to the library system, where would you prefer the page numbering to start? Is titlepage page 1, or is the first non-generated content page 1?

josteinaj commented 6 years ago

@KariRudjord and I discussed this today, and we agreed that the desired behavior as described in https://github.com/nlbdev/pipeline/issues/78#issuecomment-341375679 is still what we want. Since the rebase of dotify has to happen at some point anyway, we would like it if you could try make it so that page 1 is on the titlepage @bertfrees. The page number should still not be rendered in the generated content (titlepage/about/toc).

However, if it turns out that it requires an unexpected big amount of work to get it working, we would be ok with page 1 being on the first page of non-generated content though.

To extract a total page count for our library system, we will use a different mechanism (i.e. calculate based on output PEF and show in HTML report).

josteinaj commented 6 years ago

I've added a page numbering test here: 9c5b5a24299a40b92e26d52f0fca955e16ac1a48

Other tests will probably have to be updated as well, but initially this test can be used to make sure numbering is correct.

bertfrees commented 6 years ago

I've updated the CSS like this: https://github.com/nlbdev/pipeline/commit/86ad966bbed726ae85b1afb4a88ada9d57bdc7ae