Hi Daniel, On 03/21/2014 08:41 PM, dmg wrote: > Sorry I wasn't specific enough. Yes, pen strokes. The reason is that > with a pressure sensitive stylus, handwritten text is nicer and more > readable. > > but sometimes I would like to change the thickness of the text after I > have written it without rescaling it. > > Maybe what we need is an option that defaults to set width. If not > set, rescales width. > > I guess the problem is that strokes do not record the maximum width > text was written with them. The only feasible way is > to scan the text, find the maximum width, and rescale accordingly: > newWidth = oldWidth * currentWidth/ maxWidth. That would > work for me.
Actually strokes DO record the nominal width of the brush (which isn't quite the maximal width, assuming your stylus uses its full nominal pressure range -- the maximal width that a variable-width stroke can reach is slightly more than the width of the corresponding fixed-width stroke). Cf. width_minimum_multiplier and width_maximum_multiplier constants in the config file, and the code for get_pressure_multiplier() in xo-misc.c). The nominal width is in item->brush.thickness, and if item->brush.variable_width is TRUE then item->widths contains the widths of the various segments. Currently, rethicken_selection() in xo-selection.c just changes item->brush.width, and sets item->brush.variable_width to FALSE. item->widths remains unchanged (isn't rescaled, but becomes ignored since variable_width becomes FALSE; the undo/redo code uses this to be lazy and also ignore completely item->widths, it simply swaps all the brush data which will restore variable_width to TRUE... it just works even though it's counterintuitive!). What you'll want to do instead is, at the very end of rethicken_selection(), remove item->brush.variable_width = FALSE; and instead do something like (adding a local variable int i) for (i=0; i<item->path->num_points-1; i++) item->widths[i] *= item->brush.thickness / brush->thickness; However you'll also need to change the undo/redo code, in xo-callbacks.c: in the block else if (undo->type == ITEM_REPAINTSEL) { ... } where it currently says // remark: a variable-width item might have lost its variable-width add if (it->brush.variable_width) { for (i=0;i<it->path->num_points-1;i++) it->widths[i] *= it->brush.thickness / tmp_brush.thickness; } (at this point in the code the brushes have been swapped already so tmp_brush contains the brush used after the operation being undone, while it->brush is the brush info before the operation). Exactly the same in the redo code (insert exactly the same code in the same place in the ITEM_REPAINTSEL case block). Not promising that I got it right -- I didn't test -- but it's close enough that you should be able to figure out how to fix it if I got it wrong. Doing it with an option is slightly more annoying but you get the idea. Note: if you make the option have a menu entry, then there's a subtlety: in the undo/redo code, to decide which behavior to have, you'd test not whether the option is active right now, but whether it was active when the initial operation was performed, by comparing the variable_width flag in it->brush and tmp_brush: if one is true and the other false then the repaint operation killed the variable width feature. Actually there's a smarter way to do this: always rescale the widths[] arrays both in rethicken_selection() and in undo/redo code as if the behavior you want were enabled, and simply make the line "item->brush.variable_width = FALSE;" in rethicken_selection() conditional on the option (then it doesn't matter if the widths array gets updated as in the new behavior, since the variable_width flag being set to false causes it to be ignored. Umm, by the way we might be leaking some memory with the widths arrays of resized strokes when we destroy the journal -- since I'm not sure if we destroy the widths array when the stroke is no longer marked as variable-width; in fact I think we forget to destroy it in delete_layer() in all cases, at least I don't see where it gets destroyed ever, probably an omission on my part. What I don't know is if there's ever a risk that a stroke might have a nominal brush width of 0 (the only significant way I can see this happening is by rescaling the stroke to something so fine as to be below 0.01 point, then saving to file which rounds things to 2 decimal places). Given that the "very thin" pen is normally at 0.42 point, you'd need to resize a selection box containing "very thin" strokes and make its size at least 80 times smaller than the original one (e.g. by squishing the selection box to a single point), then save and reload, for the journal to contain strokes of nominal width zero. However, in the rather unlikely event that someone ever does this, and then tries to change the thickness, they'd crash the new code with a division by zero. Best, Denis -- Denis Auroux aur...@math.berkeley.edu University of California, Berkeley Tel: 510-642-4367 Department of Mathematics Fax: 510-642-8204 817 Evans Hall # 3840 Berkeley, CA 94720-3840 ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel