3

According to the Documentation, "Dingbats are placed to the left of the main contents of a cell, aligned with the first line of the contents." But when I evaluate

CellPrint@Cell[BoxData["Text"], CellDingbat -> "CellDingbat"]

in a Notebook with the "Default" stylesheet I get

screenshot

One can see that the CellDingbat is placed lower than the first line of the Cell. Why this happens? Is there a way to align CellDingbat with the first line of the Cell?

Alexey Popkov
  • 9,355
  • 4
  • 42
  • 93
  • Alexey: Why do you need to have `BoxData` wrapped around your cell contents? Are you actually putting the `CellDingbat` on an "Input" type cell or just on a formatted "Text" or "Section" type cell? – Simon Sep 29 '11 at 12:26
  • @Simon I use `CellDingbat` for `Cells` without predefined styles but with explicit set of options (the reason is explained [here](http://stackoverflow.com/questions/5690659)). And `BoxData` is unavoidable because I generate formatted `Cell`s. – Alexey Popkov Sep 29 '11 at 13:40
  • But can you use the construct `Cell[TextData[Cell[BoxData[...]]], CellDingbat->"dingbat"]` as shown in my new answer? (You don't need to use any predefined styles) – Simon Sep 29 '11 at 13:47

5 Answers5

4

It looks like the baseline of the dingbat and cell contents don't change in the same way when the cell contents are wrapped in BoxData. As Sjoerd pointed out, removing the BoxData from the cell contents makes things line up, but adding BoxData to the CellDingbat does not seem to change anything.

The baseline can be shifted using an AdjustmentBox and after playing around for a while, I found that the baseline is out by CurrentValue["FontAxisOffset"]/CurrentValue["FontMWidth"]. Both of these terms change with the Magnification but it turns out that the observed offset is the constant value obtained when Magnification->1. In this case, the ratio is 0.20833 == 5/24.

I'm not sure if the problem really is with the baseline and whether there is a good underlying reason for the behaviour. I'm also not sure why the required shift does not depend on the magnification of the Cell, Notebook or $FrontEnd. But it seems to work and I've spent enough time playing around with it!

So to test that everything is (basically) ok, try

Do[CellPrint@Cell[BoxData["TxyT"], 
      CellDingbat -> BoxData[AdjustmentBox["TxyT", BoxBaselineShift -> -5/24]], 
      Magnification -> mag], {mag, 1, 5}]

dingbats

And also test how

CellPrint@Cell[BoxData["TxyT"], 
   CellDingbat -> BoxData[AdjustmentBox["TxyT", BoxBaselineShift -> -5/24]], 
   Magnification -> Inherited]

looks for various magnifications of the containing notebook and frontend, e.g.,

SetOptions[EvaluationNotebook[], Magnification -> 4.]

and/or

SetOptions[$FrontEnd, Magnification -> 4.]
Community
  • 1
  • 1
Simon
  • 14,631
  • 4
  • 41
  • 101
  • On my machine (*Mathematica* 7.0.1 under Windows XP) `BoxBaselineShift -> -4/24` gives the correct placement shown on your screenshot. Probably this value is version and OS-dependent. – Alexey Popkov Sep 29 '11 at 03:14
  • It also depends on the font used: specifying different fonts for `CellDingbat` and `BoxData` breaks alignment again: ``Do[CellPrint@ Cell[BoxData["TxyT"], CellDingbat -> BoxData[AdjustmentBox[StyleBox["TxyT", FontFamily -> "Times"], BoxBaselineShift -> -4/24]], Magnification -> mag], {mag, 1, 5}]``:. – Alexey Popkov Sep 29 '11 at 03:20
  • @Alexey: OK, I'm runnning Mma 8.0.1 in linux. Is the `CurrentValue["FontAxisOffset"]/CurrentValue["FontMWidth"]` ratio different on your machine? This should also change with the fonts, so maybe you should use `BoxBaselineShift -> Dynamic[-CurrentValue["FontAxisOffset"]/CurrentValue["FontMWidth"]`, or something similar using the *obj* argument of [CurrentValue](http://reference.wolfram.com/mathematica/ref/CurrentValue.html) – Simon Sep 29 '11 at 04:04
  • `CurrentValue["FontAxisOffset"]/CurrentValue["FontMWidth"]` gives 25/99 but this value changes when I change Magnification. `Options[$FrontEnd, Magnification]` is set to `{Magnification -> 1.5}`. `BoxBaselineShift -> Dynamic[-CurrentValue["FontAxisOffset"]/CurrentValue["FontMWidth"]` does not give the correct placement. – Alexey Popkov Sep 29 '11 at 08:59
  • @Alexey: Damn... I was hoping that this ratio would be the correct shift irrespective of system and setup. I guess that my guess (and hopes) were no good! Sorry... – Simon Sep 29 '11 at 11:14
  • Seemingly these things are still not implemented properly. You should not apologize. Thank you for your effort! I also thought of `\[AlignmentMarker]` but found no way to use it in this case. – Alexey Popkov Sep 29 '11 at 11:21
3

CellLabel instead of CellDingbat

Dingbats are normally little icons, not text. By design, they are positioned somewhat under the baseline of the contents of the first line of the cell. To my eye, they look fine that way.

If you want a label for the cell, instead of a Dingbat, use CellLabel:

CellPrint@Cell[BoxData["Text"], CellLabel -> "Example"]

cell label

You can handle the left allignment through CellMargins.

If you prefer the label on the left, have the cell formatted as Output, but notice that the alignment will depend on the screen magnification as the following 3 examples show:


magnify 1


times one and one half


times 2


DavidC
  • 3,056
  • 1
  • 20
  • 30
  • 1
    By the way, did anyone notice that the black circle dingbat in the third example (200% magnification) moved to an entirely new position, away from `In[29]:=`. I only used the example to highlight `CellLabel`'s, but something weird happened to the dingbat of the input cell! – DavidC Sep 29 '11 at 21:03
2

I noticed that if you replace BoxData with TextData (or remove BoxData, leaving "Text") the dingbat and the cell contents are aligned.

Sjoerd C. de Vries
  • 16,122
  • 3
  • 42
  • 94
2

Provided you don't want the CellDingbat on a standard "Input" or "Code" cell style, then as pointed out by Sjoerd, the cell's contents and dingbat automatically align. It's only when you wrap the cell contents in BoxData that they become misaligned.

If the cell you want is a "Text" or "Section" (etc) cell, then you can still have formatted text provided the cell contents are contained in TextData[...]. For example

dingBaT

Note that I've started the text and ended the dingbat with a capital T so that the alignment is clear.

If you hand make your "Input" cells to have their contents wrapped in TextData (which does not happen by default) then the code will run, but the styling is not quite right. The spacing is wrong and syntax highlighting not active. Compare the following

input

The first printed cell has syntax highlighting but the cell dingbat is misaligned, while the second printed cell has no syntax highlighting and poor spacing, but the dingbat is perfectly aligned!


Finally, I should have realised that a solution like this would work, because I've been using cell dingbats for automatic section numbering for ages and have never had alignment problems. E.g., here's the outline of a notebook I was working on last week that contains supporting code for a chapter in my thesis:
WZ
The section and subsection cells are given dingbats in the stylesheet, e.g.,
CellDingbat->TextData[{CounterBox["Section"], ". "}].

Community
  • 1
  • 1
Simon
  • 14,631
  • 4
  • 41
  • 101
  • Quick tests have showed that `Cell[TextData[Cell[BoxData[...]]], CellDingbat->"dingbat"]` works perfectly. Thank you very much! – Alexey Popkov Sep 29 '11 at 14:12
1

Does specifying the CellBaseline have any effect?

As in

CellPrint[
 Cell[BoxData["Text"], CellDingbat -> "CellDingbat", 
  CellBaseline -> Bottom]]

rather than the default CellBaseline -> Baseline

681234
  • 4,214
  • 2
  • 35
  • 42
  • Actually, that seems to work perfectly! (I thought I had tried all the options of the form `"*Baseline*"`... oh well) – Simon Sep 30 '11 at 02:01
  • It does not work when different fonts are used: `CellPrint[Cell[BoxData["Text"],CellDingbat->StyleBox["CellDingbat",FontFamily->"Times"],CellBaseline->Bottom]]`. – Alexey Popkov Sep 30 '11 at 04:08