cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can change your system assigned username to something more personal in your community settings. X

EXTERNAL: Rotated text in table header rows (FOSI)

ebenton
1-Newbie

EXTERNAL: Rotated text in table header rows (FOSI)

For those of you following along at home, I hacked the TeX code in the FOSI to move the rotated text over to the right by changing the original code from this:
<usetext source="%\hbox{\special{pub:" rotate=" 90}%,10pt,#content,%}%&quot;="></usetext>

To this:
<usetext source="%\hbox{" }\hbox{=" }\hbox{=" }\hbox{\special{pub:=" rotate=" 90}%,10pt,#content,%}%&quot;="></usetext> (The curly braces in the initial 3 \hbox{ } "commands" need to have a space in them. Empty curly braces won't work.)

There is probably a better, more elegant and more "TeX-y" way of doing this, but for now, this works.
6 REPLIES 6

Looks like you got it. I don't remember the exact presentation problem we
ended up with after deploying the tex, but we futzed around with cell
padding, removed it all (on one side?). Can't remember. I could look it up
if you want it


Thanks, but that is not necessary. I tried aligning the text right and that did nothing, but once again, I did not think of doing cell padding on the left. Duh (again).

It looks like cell padding does have an effect and would probably work OK on most tables, but when you have a table with many, or any number of, narrow columns, the necessary amount of cell padding can be a significant percentage of the cell width. The cell padding PI does not seem to be able to be applied to just one row. It's either the whole table or nothing. This is fine for the header row, where my text is formatted vertically, but for the remaining non-header rows with narrow columns, it can screw up the formatting of the contents of those cells.

Here is an XML sample and some of the e-i-c's we've used. Turns out it
wasn't cell padding ... it was futzing with the offset. I think. Again,
this is old ... we used it until tables started supporting the rotate
attribute and I stripped most of it out. I think I still support the
<rotate> element somewhere but I'm not sure anyone uses it anymore.

<entry align="center" valign="bottom">
<para>!,%\hbox{\special{pub: rotate 90}%,<rotated_impact_cell.fmt>,\Key
Lime Pie\,</rotated_impact_cell.fmt>,%}%,!</para>
</entry>

<e-i-c gi="rotate">
<charlist inherit="1" charsubsetref="suppress">
<usetext source="%\hbox{\special{pub:" rotate<br="/>90}%,<rotated_cell.fmt>,#CONTENT,</rotated_cell.fmt>,%}%">
<subchars></subchars>
</usetext>
</charlist>
</e-i-c>
<e-i-c gi="rotated_cell.fmt">
<charlist inherit="1">

</charlist>
</e-i-c>
<e-i-c gi="rotated_impact_cell.fmt">
<charlist inherit="1">

</charlist>
</e-i-c>


Geez, another table formatting attribute that I haven't ever played with much. Thanks.

I think that's actually messing with the text's baseline. If I'm
remembering correctly (and I could be wrong ... did I say I wrote that code
a long time ago, right?!), the baseline on TeX rotated text is - for right,
+ for left.

Truth be told, it's probably Trudy Bihlmeyer's code I just copy/pasted.
Then tweaked.


Top Tags