The image node placement code doesn't doesn't handle directional changes, which results in wrong placement of images in right-left (and other) directions, see the attached simple test suit (all images should fit into the frames). This patch attempts to fix this, but it does handle _LT/_LB and _RT/_RB only, as I can't test the others in PDF mode. Regards, -- Khaled
Hi Khaled, On Wed, 7 Jan 2009, Khaled Hosny wrote:
The image node placement code doesn't doesn't handle directional changes, which results in wrong placement of images in right-left (and other) directions, see the attached simple test suit (all images should fit into the frames). This patch attempts to fix this, but it does handle _LT/_LB and _RT/_RB only, as I can't test the others in PDF mode.
thanks for the patch and test files, looks fine. One question is not clear to me: Why do you use font_direction() and not box_direction()? E. g., dir_TL_ instead of dir__LT? Isn't an image something line/page oriented? Would you run into problems if images would be box_direction() based? You can still move them perpendicularly to the base line by height/depth. (I just switched rule handling to box_direction(), it was also based on font_direction, but many directions didn't produce a rule at all.) Regards, Hartmut
On Wed, Jan 7, 2009 at 11:51 AM, Hartmut Henkel
Hi Khaled,
On Wed, 7 Jan 2009, Khaled Hosny wrote:
The image node placement code doesn't doesn't handle directional changes, which results in wrong placement of images in right-left (and other) directions, see the attached simple test suit (all images should fit into the frames). This patch attempts to fix this, but it does handle _LT/_LB and _RT/_RB only, as I can't test the others in PDF mode.
thanks for the patch and test files, looks fine. One question is not clear to me: Why do you use font_direction() and not box_direction()? E. g., dir_TL_ instead of dir__LT? Isn't an image something line/page oriented? Would you run into problems if images would be box_direction() based? You can still move them perpendicularly to the base line by height/depth.
(I just switched rule handling to box_direction(), it was also based on font_direction, but many directions didn't produce a rule at all.)
Regards, Hartmut
I was working on an older svn revision and I tried to follow rule handling. I redid it to use box_direction instead, I didn't spot any problems so far. -- Khaled
Hi Khaled, On Thu, 8 Jan 2009, Khaled Hosny wrote:
I was working on an older svn revision and I tried to follow rule handling. I redid it to use box_direction instead, I didn't spot any problems so far.
thanks again, i have applied it. But i'm now not sure anymore if it is allowed to change font_direction to box_direction (as i proposed) in the output part, since the TeX machinery may assign e. g., height/depth to "running" \vrules and to the surrounding hboxes depending of orientation of internal stuff. This needs to be in sync with the output part. I'll try to check how things are packed. So maybe the font_dir --> box_dir patch needs to be reverted... Regards, Hartmut
On Fri, Jan 9, 2009 at 11:30 PM, Hartmut Henkel
Hi Khaled,
On Thu, 8 Jan 2009, Khaled Hosny wrote:
I was working on an older svn revision and I tried to follow rule handling. I redid it to use box_direction instead, I didn't spot any problems so far.
thanks again, i have applied it. But i'm now not sure anymore if it is allowed to change font_direction to box_direction (as i proposed) in the output part, since the TeX machinery may assign e. g., height/depth to "running" \vrules and to the surrounding hboxes depending of orientation of internal stuff. This needs to be in sync with the output part. I'll try to check how things are packed. So maybe the font_dir --> box_dir patch needs to be reverted...
Thanks! I'll try to look at it again next week (quite busy now), I'm trying to understand I'm trying to understand more how this stuff works. Regards, -- Khaled
On Fri, Jan 09, 2009 at 11:24:45PM +0200, Khaled Hosny wrote:
thanks again, i have applied it. But i'm now not sure anymore if it is allowed to change font_direction to box_direction (as i proposed) in the output part, since the TeX machinery may assign e. g., height/depth to "running" \vrules and to the surrounding hboxes depending of orientation of internal stuff. This needs to be in sync with the output part. I'll try to check how things are packed. So maybe the font_dir --> box_dir patch needs to be reverted...
Thanks! I'll try to look at it again next week (quite busy now), I'm trying to understand I'm trying to understand more how this stuff works.
This new patch fixes BL_ and BR_ directions in vlist, it wasn't working properly with the former patch. Regards, -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
On Tue, 20 Jan 2009, Khaled Hosny wrote:
This new patch fixes BL_ and BR_ directions in vlist, it wasn't working properly with the former patch.
thanks a lot, but it seems it's not sufficient. The hpack/vpack algorithms don't get the right image dimensions, so the surrounding box sizes aren't calculated right and therefore \hrules and \vrules around the pictures are not always correct (i won't touch this now). Regards, Hartmut
On Wed, Jan 21, 2009 at 12:36:49AM +0100, Hartmut Henkel wrote:
On Tue, 20 Jan 2009, Khaled Hosny wrote:
This new patch fixes BL_ and BR_ directions in vlist, it wasn't working properly with the former patch.
thanks a lot, but it seems it's not sufficient. The hpack/vpack algorithms don't get the right image dimensions, so the surrounding box sizes aren't calculated right and therefore \hrules and \vrules around the pictures are not always correct (i won't touch this now).
Ah, I see this, and I think I found why. This patch fixes this (at least with my simple tests). Regards, -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Hi Khaled, On Thu, 22 Jan 2009, Khaled Hosny wrote:
Ah, I see this, and I think I found why. This patch fixes this (at least with my simple tests).
thanks, but please see page 2 in the attached file: The last pair of \vrules are not surrounding the image. I guess that's a sign that the image size isn't properly taken into account when doing the boxing, which is the task of these hpack and vpack functions. I have never touched either, and i don't want to risk tweaking them. But if you see a way to fix it, please go ahead. Regards, Hartmut
On Thu, Jan 22, 2009 at 10:54:29PM +0100, Hartmut Henkel wrote:
Hi Khaled,
On Thu, 22 Jan 2009, Khaled Hosny wrote:
Ah, I see this, and I think I found why. This patch fixes this (at least with my simple tests).
thanks, but please see page 2 in the attached file: The last pair of \vrules are not surrounding the image. I guess that's a sign that the image size isn't properly taken into account when doing the boxing, which is the task of these hpack and vpack functions. I have never touched either, and i don't want to risk tweaking them. But if you see a way to fix it, please go ahead.
This seem to be another issue than what this patch is trying to fix. I think it is safe to apply this patch as hpack/vpack issue seems not to be image specific (I can reproduce it with rules too). Regards, Khaled -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
participants (2)
-
Hartmut Henkel -
Khaled Hosny