2

I want to minimize conversion error when working with PSTricks and (La)TeX. The conversion error really affects the accuracy of bounding box, the thickness of LaTeX's \fbox and the thickness of PSTricks stroke.

When I specify a length for

  1. page layout dimension: \paperwidth, \paperheight, \voffset, \hoffset, \topskip, \parindent
  2. TeX box dimension: \fboxrule, \fboxsep, \arrayrulewidth, etc
  3. PSTricks object dimension: \unit, \linewidth, etc

which unit should we use to minimize the conversion? Should we use a single unit throughout the document?


Because the existing answers don't explain how to minimize the conversion error, I will emphasize and rephrase my questions above. Based on the existing answers, my understanding is as follows.

TeX naturally works in sp and PostScript works naturally in bp. If I want to avoid conversion in TeX block, provide the lengths in sp. But if I work in PSTricks block, I must provide the length in bp.

However, I have one question:

If I define a \pspicture dimension in bp, how does PSTricks ask TeX to reserve the space without making a conversion error from bp to sp?

9
  • You do know that TeX always works internally in sp (integer) values, I assume?
    – Joseph Wright
    Jul 14, 2011 at 12:58
  • @xport: The TeX part of PSTricks will most likely work in the TeX units (pt/sp, technically the same thing, just presented differently). However, most of the PSTricks magic is done in PostScript which uses bp. Jul 14, 2011 at 13:02
  • @xport PSTricks uses PostScript, which uses bp (72 points per inch).
    – Joseph Wright
    Jul 14, 2011 at 13:03
  • 1
    @Joseph: it is not important, that PS has bp as a default unit. Scaling the user coordinate system allows values in_any_ unit.
    – user2478
    Jul 14, 2011 at 13:36
  • 2
    @Herbert: However, there must be the potential of rounding errors. For example, as pt an bp are almost but not quite identical, it's not possible to represent both as floating point machine numbers.
    – Joseph Wright
    Jul 14, 2011 at 15:29

2 Answers 2

4

(La)TeX itself works only with pt (TeX Points, 1pt = 1/72.27 inch). These are fixed-point numbers and are internally stored as integers, i.e. multiplied by 65536. These representation is called scaled points and have the unit sp, so 65536sp = 1pt (because TeX uses 16 bit for the fractional part of a pt, 2^16 = 65536) . In other words TeX accuracy is 1/65536 pt = 1sp. Any dimension or calculation which results in a fractional sp value is rounded/truncated in an integer value. So 0.01pt = 0.01 * 65536 = 655.36 => 655sp (= 0.009994507pt). Note that you can display the sp representation of a TeX dimension using \number, e.g. \number\textwidth will give you that value in sp but without the unit attached.

If you assign any dimension to a LaTeX length or TeX dimension (defined by \newlength, \newskip or \newdimen) it is converted to sp internally (but presented to the user as pt), even if you use another unit like cm, bp or in. This answers your points 1 and 2: it doesn't matter really because it is converted anyway. If you want to keep it in e.g. bp you need to store this value in a macro as string content instead. (graphics/x actually does that; it also strips the bp unit off)

Postscript rounds the point to simpler fraction: 1 PS pt = 1/72 inch. TeX calls this big points because they are slightly larger than TeX points and provides the bp unit for it. If you provide lengths to PostScript code directly, then you need to do this using bp not pt. Sometimes it is necessary to strip of the unit in addition (like for the BoundingBox header).

I assume the higher level interface of pstricks should handle pt/bp by itself. However, \special calls and direct postscript code needs to be handled by yourself. I would keep all units pt to avoid rounding errors by TeX and only convert it at the very end if possible.

15
  • You mean by looking at it? Your viewer might not be able to show the difference. There are often also aliasing effects. Jul 14, 2011 at 13:16
  • @Martin I hope you don't mind, but I fixed an error in your post: you had a PS point = 72 in. A point is not six feet long...
    – Seamus
    Jul 14, 2011 at 13:34
  • @xport: \message{\number\dimexpr 1bp\relax} tells me 65781. See my last update. Jul 14, 2011 at 13:36
  • 2
    One should also note that TeX does "truncated division": after \dimen0=100sp\divide\dimen0 3, \dimen0 will be 33sp; after \dimen0=99sp\divide\dimen0 2, \dimen0 will be 49sp. Operations with \dimexpr round: \dimen0=\dimexpr99sp/2\relax will load 50sp in \dimen0. Truncation has some consequences: the well known example of \hbox to 2in{\hskip 1in\hskip 1in} results in an "Underfull \hbox" message.
    – egreg
    Jul 14, 2011 at 13:38
  • 1
    @xport: The equal to 16 bit, i.e. 2^16 = 65536. Jul 14, 2011 at 14:22
3

PostScript does not know of any unit, everything is in bp. PSTricks can handle values with or without any unit. If a unit is missing the current one is taken into account. PStricks does everything in pt, as TeX itself also does. The PostScript user coordinate system is scaled to pt before all values are passed to PS.

2
  • So 123, 123bp and 123pt would all be taken as 123 / 72 inch by PostScript, wouldn't it? I mean inside PostScript code e.g. inserted by \special. Jul 14, 2011 at 13:39
  • no, that are 123cm (cm is default unless no other unit is set), 123bp, and 123pt, three different values for PSTricks and for PostScript!
    – user2478
    Jul 14, 2011 at 13:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.