Justify options for Text action

Bug #386494 reported by Juho Vepsäläinen
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Phatch
Fix Released
Undecided
Juho Vepsäläinen

Bug Description

This patch implements https://blueprints.launchpad.net/phatch/+spec/text-justification . I removed the offset fields and replaced them with justification options. I changed the middle item of horizontal justification to "middle" just to be consistent with vertical justification. In both cases "middle" is also the default option selected.

Tags: patch
Revision history for this message
Juho Vepsäläinen (bebraw) wrote :
Revision history for this message
Stani (stani) wrote :

Hi Juho, very good. But we need to keep the offsets field. Probably they are better renamed to position fields. They are the insertion points for the text from where the justification begins. Can you fix that? Thanks!

Changed in phatch:
assignee: nobody → Juho Vepsäläinen (bebraw)
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Juho Vepsäläinen (bebraw) wrote :

Alright.

I could implement something like this:
Horizontal/vertical justify middle:
Default offset value 0%. Offset range -100% to 100% from border to border. The position of text would be calculated so that the left/right bound doesn't go past edge on maximum (100%). This would be pretty much equivalent of the current behavior except that it keeps text inside bound for values between -100% and 100%.

In case of left/right, top/bottom things get a bit different:
Default offset value 0%. Offset range depends on selected option according to following rules:
left/top -> offset range set as 0% to 100% (negative offset would go past border)
right/bottom -> offset range set as -100% to 0% (same with positive).

So the effect of choosing any other than "middle" option would cause changes in behavior of offset due to the nature of zero. :)

I admit that the proposed solution seems perhaps a bit too complicated. Let me know if you have something neater in mind.

I agree that renaming "offset" as "position" might reflect its purpose better. I'm fine with the change.

Revision history for this message
Stani (stani) wrote :

"The position of text would be calculated so that the left/right bound doesn't go past edge on maximum (100%). This would be pretty much equivalent of the current behavior except that it keeps text inside bound for values between -100% and 100%."
I would not go this route. This becomes unpredictable for the user. What if the text is bigger than the image? The old behavior is the only correct one for me. The default values for the text action would be:
Horizontal Position: 50%
Vertical Position:50%
Horizontal Justification: Middle
Vertical Justification: Middle

The position fields have to be PixelFields. Be sure to pass absolute values in pixel_fields (see the original text action). The position *really* has to be absolute, as later I'd like to add a rotation angle field, or draw as circle (which would need a radius), ... For this we would change the name of the Orientatien field in "Layout", which can everything which it is now but including: "Rotate By Angle" and "Circle". In case of rotate by angle, an angle field would pop up and in case of circle a radius (=pixelfield). Circle layout would be very nice in combination with the badge action list from the library. Try it if you didn't have yet.

Stani (stani)
Changed in phatch:
importance: Medium → Undecided
Revision history for this message
Juho Vepsäläinen (bebraw) wrote :

I restored the offset values. Basically the workflow goes as follows:
1. Figure out where you want to justify (suppose top-left in this case) and set values. Note that it always snaps to the edge so that you can expect the text to be inside the image.
2. Figure out how much to offset (suppose we want to move the text a bit right and a bit down). In this case horizontal and vertical offset could be set to 5% or some other suitable value. Thanks to snap it's easier to estimate the offset value.

So the general rule is that positive values increment towards down/right (same as the old behavior!).

Note that I did not implement any other advanced options yet. Hopefully it's a bit better now. :)

Revision history for this message
Stani (stani) wrote :

Thanks for the patch! I just tweaked the behaviour a bit so that justification is relative and offset is absolute.

Changed in phatch:
status: Incomplete → Fix Committed
Revision history for this message
Stani (stani) wrote :

AFAIK, this patch has been committed.

Stani (stani)
Changed in phatch:
milestone: none → 0.2.1
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.