This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current main page.

Image sizes are inconsistent → sometimes awful layout

There is a ticket for this issue.

I tried making a pdf of HSL and HSV, (link to the pdf), but because of the idiosyncratic image sizes, the result is a rather broken layout. The size specified (300px, 400px, or whatever) seems to be ignored by the renderer. The render size seems to depend on the size and internal resolution metadata of the original image, rather than the size specified on the wiki page. The result is that a screen-sized image (bottom of page 3 in the pdf) is rendered tiny, while some images intended to be essentially thumbnails are rendered somewhat large (top of page 4). Particularly noticeable, sets of images placed side-by-side and intended for same-size rendering (pages 8, 14, 15) end up different sizes, some of them too small to see. Also, floated image pairs using the “double image” template don’t seem properly supported: they don’t float.

A couple more issues, that I’ll stick here because they can be seen in that same rendered pdf.

HTML tables with explicit CSS width on the cells don’t seem to be properly handled (pages 19-23), and those tables seem to have some other odd rendering issues (e.g. the "1" headings at near the top right of each table are rendered lower and not bold, and many of the cells are oddly taller than expected).
Text paragraphs near images have some weird sizing and spacing. See for instance page 12.
Paragraphs are justified, but no hyphenation is used, leading to unsightly rivers of whitespace (“automatic typography” at its worst).

I suppose the main problem here is that layout considerations in writing wiki pages are designed around the expected size of type in a browser window, rather than of a printed page, and many wiki articles use images at small sizes which can easily be clicked/expanded in online use but should be larger in print. I’m not sure there’s any good automatic way to decide at what size an image would look good in a pdf – the images in the HSL & HSV article are big in the original because they are diagrams which form an essential part of the explanation in the text, while images in other articles are incidental and thumbnailed. I’d be glad to add sizing notes for print in the article’s wikitext if such hints could be used by the pdf rendering. Until such finer control is possible, though, the quality of a pdf created by just printing the web page with a browser is somewhat higher than that of the pdf rendered with this “books” software.

Cheers,
jacobolus (t) 19:40, 2 March 2010 (UTC)

Yeah, it's nothing easy to fix. That being said, the layout of that page is not that great either, most images are on the right, and WP:MOSIMAGE suggest alternating them between left and right. Also, several methods are used to place images, some are bare files, others are thumbnailed, and others are in double/triple images templates, often with {{clear}} templates around them. It would probably look much better if images were inserted a bit more consistently. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 19:57, 2 March 2010 (UTC)

Basically, the layout works reasonably well on the web, given the constraints of wiki layout (those different display methods are motivated by differences in the size, use, form of the images in question), but it provides a pretty decent “stress test” of this pdf renderer, and essentially knocks it over. :-) The only solutions I can see are (a) writing articles without many diagrams and just accepting degraded explanatory quality, or (b) allowing some kind of customization of pdf layout. –jacobolus (t) 20:03, 2 March 2010 (UTC)

Actually some more suggestions:

It seems that paragraphs sometimes don’t properly “wrap” around images which float past a paragraph. Approximately the right thing happens on page 1, but I can’t explain the behavior of page 2. This especially seems to prevent mathematics (or perhaps paragraphs indented by “:”, common on wikipedia) from wrapping. The image on page 7 isn’t floated at all – perhaps because it is followed by a bulleted list?
The indentation of a colon-indented bit of math or text is too much. Seems to be a full half inch, or about twice as much space relative to text size as on the web.
If two images are floated in a row, but with a paragraph of text shorter than the height of the first image in between, the render implicitly clears before starting the paragraph after that, putting it in line with the second image (e.g. page 6).
The cquote template is broken (see page 14): given that it renders text on the web with the same size and spacing as normal body text, there’s no reason for it to render text smaller in the pdf; it needs more margin on both right and left; the large decorative quotation marks are misplaced.
The nowrap template is ignored; it should prevent equations, etc. from wrapping from one line to the next.
Subscripts are too far below the baseline, and superscripts too far above it; both are probably a bit too large.

–jacobolus (t) 20:16, 2 March 2010 (UTC)

Substitute templates (2)

There is a ticket for this issue.

Substitute templates don't appear to work with redirects.

That is, if a template (or infobox) was renamed, e.g. from Template:PDF test template3 to Template:PDF test template, in the PDF, the replacement of Template:PDF test template3 with Template:PDF test template/Print doesn't happen.

Sample here. -- User:Docu

I created a bug report for this problem.Headbomb {talk / contribs / physics / books} 15:47, 20 March 2010 (UTC)

Bug: LaTeX formulas not shown in ODF files

There is a ticket for this issue.

I'm trying to get ODF files from math articles (and books at pt.wikibooks) but the formulas are not shown:

Example: http://en.wikipedia.org/w/index.php?title=Special:Book&bookcmd=rendering&return_to=Special:Book&collection_id=2f98bc4ad3e57417&writer=odf

This makes the files useless for such pages... =/ Helder (talk) 13:17, 20 March 2010 (UTC)

See the above bug report. Headbomb {talk / contribs / physics / books} 15:49, 20 March 2010 (UTC)

Bug: It is not possible to define a chapter to have only one wikipage

When we try to use the book functionality for creating PDF versions of wikibooks, it's likely that each chapter will be made of exactly one wikipage of the wikibook. For example, suppose we have this book:

Sample book/Sample first chapter
Sample book/Sample second chapter

So, when we try to create the PDF using this extension, there is no way to make a nice PDF because the current options are:

To use this syntax:

:[[Sample book/Sample first chapter|Sample first chapter]]
:[[Sample book/Sample second chapter|Sample second chapter]]

or

To use this syntax:

;Sample first chapter
:[[Sample book/Sample first chapter|Sample first chapter]]
;Sample first chapter
:[[Sample book/Sample second chapter|Sample second chapter]]

In both cases the resulting PDF isn't properly formated:

In the first situation the chapter's names are formated as if they were subchapters, not as if they were chapters (and at Wikibooks the pages are usually chapters, so the titles should be centralized and with lines at top/bottom) and "Sample second chapter" usually starts in the middle of a page (instead of at the top, because the previous page isn't filled with blank space)
The second case shows each title two times, alghout it solves the formating of title and each chapter now starts in a new page. But this repetition is uggly... =/

The extension could be more useful if it allows a way to handle this cases. Maybe this syntax should work and give the expected results:

;[[Sample book/Sample first chapter|Sample first chapter]]
;[[Sample book/Sample second chapter|Sample second chapter]]

What do you think? Do we have any other options? Helder (talk) 15:16, 20 March 2010 (UTC)

I don't see what's wrong with any of these. I think you misinterpret the structure. Essentially, articles are subchapters, thus articles titles are treated as sub-chapters titles. So the structure is


== Title ==

== Subtitle ==

;Chapter 1
:[[Subchapter 1.1]]
:[[Subchapter 1.2]]
:[[Subchapter 1.3]]
;Chapter 2
:[[Subchapter 2.1]]
:[[Subchapter 2.2]]
:[[Subchapter 3.3]]

See Book:Hadronic Matter for a book that follows this structure. If you don't include chapters, then you have

== Title ==

== Subtitle ==

:[[Subchapter 1.1]]
:[[Subchapter 1.2]]
:[[Subchapter 1.3]]
:[[Subchapter 1.4]]
:[[Subchapter 1.5]]
:[[Subchapter 1.6]]

See Book:Invincible class battlecruisers for a book that follows this structure. Headbomb {talk / contribs / physics / books} 16:04, 20 March 2010 (UTC)

My understanding is that (semantically) in order to have a subchapter, we need to have a chapter, so the Book:Invincible class battlecruisers isn't correct, because the formating of each page should be that of chapters. So, the problem is that there is no way to say to the extension that a wikipage is a whole chapter (not a subchapter). It seems that we don't have a syntax to give the right semantic for such books. Helder (talk) 12:04, 21 March 2010 (UTC)

This is somehow related to what was requested above, on #Possible additions to the book feature, but here the need is for a way to mark a page as being a chapter (this should automatically start the wikipage in a new PDF page). Helder (talk) 12:35, 21 March 2010 (UTC)

Yes, but this is semantics rather than an actual problem. When you pick a book "without chapters", you'll have a level 1 (title), level 2 (subtitle, optional), and level (subchapters) 4 headers. However, since there is no level 3 headers, the level 4 header effectively acts as a level 3 header, and subchapters are effectively chapters. Headbomb {talk / contribs / physics / books} 14:07, 21 March 2010 (UTC)

Actually it is a problem, because the Special:Book page has a link which says "Create chapter" and when the user clicks on it what he gets is just a "Title of chapter" in bold, not a link pointing to the chapter (the page called "Title of chapter"), and still he has no way to indicate that the chapter is that wikipage "Title of chapter", so that page is not a chapter...

By the way, did you see my last comment at Help:Books/Feedback/Archives/2009/November#Wrong_order, in particular the last suggestion about a change to be made in the "Sort alphabetically" feature? Helder (talk) 14:33, 21 March 2010 (UTC)

That is the intended behaviour. See Book:Hadronic Matter. And yes I did see that, in fact I gave it a long reply. Headbomb {talk / contribs / physics / books} 16:52, 21 March 2010 (UTC)

Isn't this contradictory?

The page Special:book of the extension says that chapters are those lines which will have an ";"
You said that "4 header effectively acts as a level 3 header, and subchapters are effectively chapters", so "chapters" are the lines which starts with ":" (which the extension consider as parts of the chapters, which starts with ";").
Although the wikipages at Book:Hadronic Matter are just parts of chapters, this is not always true: this is the case at Wikibooks and Wikisources, where by definition we already have books, organized as groups of chapters whose title is of the form "Book/Chapter". So we should be able to make the correspondence of wikipages that are "full chapters" with the content of the PDF's chapters, in order to get the same formatting as here. The current behaviour is confusing to the users, because when they use special:book they are being requested to add "chapters" (pages of title "Book/Chapter") into "chapters"...

Maybe a solution is to make the extension to check if there are any headers marked with ";" (level 3?) and if there is no one, just format the headers which has ":" (level 4?) as if they were marked with ";" (starting in a new page, centralized...), so that they really acts like level 3 headers. Helder (talk) 20:49, 21 March 2010 (UTC)

I said "effectively chapters", and not chapters. Also, Wikipedia is not Wikibooks or Wikisources. If you think this is something that needs to be fixed, feel free to create a ticket for it. Headbomb {talk / contribs / physics / books} 22:26, 21 March 2010 (UTC)

Moved from Help talk:Books/for experts

Color pdf-file

Can I make a PDF file with color pictures and fonts? --PiFi (talk) 22:14, 28 February 2010 (UTC)

I'm pretty sure that the PDFs come in color. Why, did they come out in black and white? Headbomb {^ταλκ_{κοντριβς} – WP Physics} 01:51, 1 March 2010 (UTC)

Changing articles to a preferred version

I suggest removing the following example from the help page:

For instance, if some article uses favour, honour, flavour, humour, but others use favor, honor, flavor, humor, you can uniformize the style to your preferred version. However if you change the style of an article for this reason, you must return the article to its original style.

I don't think that we should encourage readers to modify articles to a preferred version, even if it is only temporary. While the example of changing between American and British spelling is relatively innocuous, more significant changes to include desired but inappropriate content might not be so harmless. -- Black Falcon ^(talk) 00:35, 3 March 2010 (UTC)

Actually there are bigger problems with the use of old revisions (namely that the rendered only check for the templates used on the current version of the article, regardless of the revision), so this should be discouraged. I don't think any book uses them for the moment, so we might as well remove this section. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 00:52, 3 March 2010 (UTC)

OK, thanks! -- Black Falcon ^(talk) 01:12, 3 March 2010 (UTC)

Security concern with /Print substitution

David Göthberg pointed out recently that this substitution, assuming it overrides protection placed on the template itself, is a security hole. (currently being discussed by devs) –SJ + 21:36, 6 March 2010 (UTC)