Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Manual
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.8.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by CSMR250 - 2011-04-09
Last edited by bluebrother - 2011-04-21

FS#12057 - Manual fonts are bitmaps

The manual uses LaTeX. One of the issues with LaTeX having 30-years-old legacy components is that you specifically need to tell it to use the outline fonts that we have been used to for about 25 years. Otherwise it uses a bitmapped font by default.

The manuals found at:
http://www.rockbox.org/manual.shtml use bitmapped fonts, presumably because they haven’t used the right setting in LaTeX, which you need to do deliberately.

Since this is default behavior in LaTeX, a lot of people run in to this problem, and there are many ways to fix it. I am not an expert on LaTeX and don’t know the best way but see http://dsanta.users.ch/resources/type1.html Or see any LaTeX forum for multiple threads on this.

Closed by  bluebrother
2011-04-21 21:54
Reason for closing:  Not a Bug
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

The font in the manual has been changed but for a different reason. Closing as Not a Bug because a PDF reader rendering the PDF in a bad way is not a bug. The rendering is also highly dependent on the PDF reader itself (you can make the output of Adobe Reader almost unusable by configuring it in a wrong way).

And what is the problem caused by the manual using bitmap fonts? Also, Adobe Reader tells me that the pdf files have various fonts embedded which are either Type1 or Type3. From my understanding (and from how I understand http://en.wikipedia.org/wiki/PostScript_fonts) these are not bitmap fonts. What makes you believe the manual uses bitmap fonts?

To confirm this: Open any manual. Zoom in. The edges are jagged.
The disadvantages of bitmapped fonts are:
-The resolution is typically low and lower than a good laser printer for example. So print quality is lower than with outline fonts.
-On screen:
–Glitches are obvious when you zoom in. This has always been true.
–Modern font rendering technologies that involve sub-pixel rendering will not be used. On Windows these have been in place since XP, i.e. since 2001. So on modern systems outline fonts will be more readable than bitmap fonts at any scale.
These are well known which is why bitmapped fonts quickly fell out of use.

None of the mentioned disadvantages is a problem. It’s disadvantages, but it’s general disadvantages bitmap fonts have. Please tell me what the problem is with the manual using bitmap fonts as I asked for. Also, why is Adobe Reader with this claim lying to me in stating that the fonts used are Type1 and Type3, but doesn’t list any bitmap fonts?

-The problem is that it is hard to read. I am not sure what your question is. It is a wrong setting that has disadvantages, so it’s a problem. It will be easy to fix.
-I gave enough information to practically confirm that bitmap fonts are being used. It would be possible to make proper outline fonts out of squares but that would be crazy.

As to your question about the details of postcript font types, see the link I gave: http://dsanta.users.ch/resources/type1.html To quote from this:
“The problem is that by default TeX/LaTeX uses bitmap (i.e., Type 3) fonts instead of scalable Type 1 or TrueType fonts. These bitmap fonts are generated at the printer’s resolution, which is typically 300 or 600 dpi. Changing the resolution of bitmap fonts is no easy task and therefore the PDF readers produce terrible results when displaying these fonts on the screen. Furthermore, printing quality can be quite deceiving if the printer’s resolution does not match the one of the bitmap font.” So the presence of Type 3 fonts indicates the problem.

If its that easy as a fix why don’t you provide a patch? Also, while using bitmap fonts for sure decreases the overall quality I disagree with the “hard to read” statement. Even if the bitmap fonts are 300dpi only, a typical screen has 72dpi, and 300dpi is a reasonable resolution for printing material. So no, it’s _not_ a problem. It’s a disadvantage.

Easy in the sense of a 1 line addition to each LaTeX document. I don’t have the programming skills to patch the automatic generation of documents.
While the dpi is a problem, the disabling of subpixel rendering in a typical pdf reader would hurt reading even if the bitmaps were 10000dpi. (See http://www.ischool.utexas.edu/~ct/chi_p618.pdf and other tests.)
Anyway that’s enough from me. Up to the developers if they want to fix this. But everyone knows that the right way to do fonts is outline. Bitmap fonts only exist because of the early history of computing.

You don’t need to “patch the automatic generation of documents”, you need to patch the source. Which is, as you claim, a single line to add.

Also, bitmap fonts don’t only exist because of the early history of computing and the right way to do is not always to use outlined fonts. This claim is completely nonsense. Rockbox itself uses bitmap fonts. Does this mean it’s early computing? Or doing it wrong? Not at all. Bitmap fonts are rendered for a *specific* size and not intended for getting scaled. This has *nothing* to do with antialiasing, Rockbox itself can also use antialiased fonts. Those are *still* bitmap fonts! If claiming things please don’t mix up two completely different things. Besides, PDF is a format intended to have the same thing as you would print in a file. You *can* also read it on the screen. If you want to read the manual you can simply use the HTML version which doesn’t include bitmap fonts (well, your computer might use bitmap fonts when displaying it …)

Changing fonts for the manual isn’t trivial. This is due to the fact that the manual is build both for PDF and HTML targets, and generation behaves different between those too. Furthermore, the manual contains extended characters that should still be searchable. If LaTeX is emulating extended characters this doesn’t work anymore and therefore it’s not wanted. A similar problem exists for small caps which are used in the manual as well (especially for naming settings, and not being able to search for a setting *is* a problem).

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing