Joerg Lehmann venit, vidit, dixit 2006-03-16 17:43:
> Hi Michael,
> On 16.03.06, Michael J Gruber wrote:
>> I'm kinda getting to like the deco concept... I remembered an old post
>> by Andre, showing a method (due to J=F6rg, I think) for laying out tex=
>> along a curve. I adjusted it to the current API and coded it as a
>> decorator dubbed deco.curvedtext(). I'm attaching a simple example (ho=
>> to achieve typical line ups) and the code. The code goes into deco.py
>> (current svn). I'm unsure about the following:
>> a) Is the patch to dvifile.dvifile.putchar appropriate for going into
>> the trunk, or are there side effects (I don't know that module)?
> No, in this form it's not appropriate because this means that we adjust
> the position after each character, which is rather inefficient.
> The correct way would be to either add an option to the texrunner or
> to allow switching of the single char mode on and off in a dynamical
> way, such that you can request this feature for only parts of the
I see. It can't be a "set" option either because TeX might be running
already, and it should still be able to change the option. I implemented
a workaround, but I don't know how you think about changing class
variables from the outside...
>> sys.path.insert(0, os.environ.get("HOME")+"/lib/python/PyX-svn")
> Just a side remark: There is os.path.expanduser which allows you to
> just write os.path.expanduser("~/lib/...")
Not much shorter, but nicer.
>> for op in t.dvicanvas.items:
>> if isinstance(op, type1font.text_pt):
>> x =3D textpos + unit.t_pt*(op.x_pt+op.width_pt/2) # Ma=
ke sure we rotate with respect to the middle of the character.
>> op.x_pt =3D -op.width_pt/2
>> c.insert(op, [dp.path.trafo(x)])
> My latest version looked like:
> items =3D t.dvicanvas.items
> xs =3D [item.bbox().center() for item in items]
> trafos =3D p.trafo(xs)
> for x, op, atrafo in zip(xs, items, trafos):
> c.insert(op, [atrafo, trafo.translate(-x, 0)])
Maybe not shorter, but definitely more pythonish! Also, it's good to
avoid isinstance(). But is this code really more efficient than having
one loop running through all op? It seems we have two list
comprehensions plus one loop now instead of the single loop before.
So, here comes the diff.