Your message dated Tue, 12 Jul 2016 10:19:57 +0200
with message-id <[email protected]>
and subject line gbdfed was removed from Debian in 2011
has caused the Debian Bug report #641984,
regarding 'next' button in glyph edit window behaves wrongly after ^Q in main
window
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
641984: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641984
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: gbdfed
Version: 1.5-1.1
Tags: patch
In the gbdfed main window, you can press ^Q to transpose the display
of the font so that consecutive characters go down the columns
rather than across the rows. After doing this, pressing the 'next'
and 'previous' buttons in the glyph edit window (or, equivalently,
hitting ^N and ^P in that window) cause the wrong glyphs to be
highlighted in the main window.
For instance: load a BDF, and double-click the digit '5' to open it
in a glyph edit window. Now press the 'next' button in the edit
window. The window moves on to show the '6' glyph, and the highlight
in the main window moves on to '6' as well.
But if you do the same experiment again and this time press ^Q in
the main window before double-clicking '5', then the highlight in
the main window will move _right_ from the '5' to the 'E' in the
next column, while the glyph edit window still shows '6' as you
expected.
The problem seems to be due to deliberate action in the
fontgrid_select_next_glyph and fontgrid_select_previous_glyph
functions, perhaps because there was some original intention to have
^N and ^P move along rows even when the font was displayed in
columns. I attach a patch which fixes the problem for me by removing
the apparently deliberate but wrong code, so that in both modes, the
highlight in the main font grid window matches the glyph actually
selected in the editing window.
Cheers,
Simon
--
for k in [pow(x,37,0x13AC59F3ECAC3127065A9) for x in [0x195A0BCE1C2F0310B43C,
0x73A0CE584254AB23D5A0, 0x12878657EA814421CC92, 0x7373445BB3DA69996F4A,
0x77A7ED5BC3AA700E80B2, 0xE9C71C94ED87ADCF7367, 0xFE920395F414C1A5DB50]]:
print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <[email protected]>
diff --git a/fontgrid.c b/fontgrid.c
index b3222d5..5d9acd9 100644
--- a/fontgrid.c
+++ b/fontgrid.c
@@ -4711,10 +4711,7 @@ fontgrid_select_next_glyph(Fontgrid *fw, gint32 code)
return FALSE;
}
- if (fw->orientation == GTK_ORIENTATION_VERTICAL)
- code += (fw->cell_rows * count);
- else
- code += count;
+ code += count;
if (fw->unencoded && code > gp->encoding)
code = gp->encoding;
@@ -4794,10 +4791,7 @@ fontgrid_select_previous_glyph(Fontgrid *fw, gint32 code)
return FALSE;
}
- if (fw->orientation == GTK_ORIENTATION_VERTICAL)
- code -= (fw->cell_rows * count);
- else
- code -= count;
+ code -= count;
if (code < 0)
code = 0;
--- End Message ---
--- Begin Message ---
Version: 1.6-1+rm
gbdfed was last released with Debian 6.0 (squeeze) in
February 2011 and removed from Debian sid/unstable later in 2011 (see
http://bugs.debian.org/616376 for details on the removal). Since
support for squeeze and squeeze-LTS has now ended, I'm closing all the
remaining bugs reported against this package.
Andreas
--- End Message ---
