Scaleable image issues on Linux

Hello all,

A question relating to http://www.entrust-systems.net/

Just for a change I have run into a problem that seems to be OS
specific rather than browser specific - the box image that is acting as
a faux border for the main text block shows nasty image effects on the
outside when using either Firefox or Konqueror on Suse Linux. This
image is set to resize with the browser window (and hence the text) and
this seems to be what triggers the rendering problem.

No particular image problem in Firefox or IE on windows, it renders as
expected.

So two questions. Firstly is this problem appearing elsewhere in other
browsers or other operating systems? I have limited access to different
test platforms so any help would be very welcome. Secondly has anyone
hit this issue before and managed to come up with a solution?

Thanks, Nic

p.s. if anyone knows of a better way to handle :hover menus on IE than
the control hack I am using please let me know.

On 23 May 2006 13:17:01 -0700 nichughes (AT) mailandnews (DOT) com wrote:

A question relating to http://www.entrust-systems.net/

Just for a change I have run into a problem that seems to be OS
specific rather than browser specific - the box image that is acting as
a faux border for the main text block shows nasty image effects on the
outside when using either Firefox or Konqueror on Suse Linux. This
image is set to resize with the browser window (and hence the text) and
this seems to be what triggers the rendering problem.

No particular image problem in Firefox or IE on windows, it renders as
expected.

So two questions. Firstly is this problem appearing elsewhere in other
browsers or other operating systems? I have limited access to different
test platforms so any help would be very welcome. Secondly has anyone
hit this issue before and managed to come up with a solution?

The GIF file is corrupt. The size of the image is specified as 1048x734
whereas the size of the only image block contained is 1046x732 with a 1px
offset in vertical and horizontal. There is a local color table specified,
but no global color table. Therefore, no global background color is
specified. That leaves some pixels undefined. The process of rendering
actual pixels could very well never be placing any color values in some of
these locations, leaving them at whatever bit patterns existed in that spot
in memory by some previous usage.

Based on the comment block in the GIF file, some component of Microsoft
Office was used to build this. Seems to be buggy (no big surprise ... they
may even be doing this and compensating for it in their own GIF decoder).
I suggest rebuilding this image all over again with another tool. That or
try exporting in PNG format instead to see if that helps.

Here's what I see in the beginning of that GIF file:

000000: 47 49 46 38 39 61
GIF version 89a

000006: 18 04
screen width = 1048

000008: de 02
screen height = 734

000010: 77
0....... global color table is absent
..111.... color resolution bits = 7+1 (256 values)
.....0... global color table is not sorted
......111 global color table size = 3*2^(7+1) (256 entries, 768 bytes)

000011: 00
background color index = 0

000012: 31
aspect ratio factor = 49 (ratio is 1.000000)

000013: 21
extension introducer:

000014: fe 1a
comment extension, block size = 26
000016: Software: Micros
000032: oft Office
comment extension, block size = 0

000043: 21
extension introducer:

000044: f9 04
graphics control extension, block size = 4 (valid size)

000046: 01
000..... reserved value = 0
....000.. disposal method = 0 (no disposal specified, no action required)
.......0. user input flag = no
........1 transparent color flag = present

000047: 00 00
delay time = 0 (0.00 secs)

000049: 00
transparent color index = 0

000050: 00
empty data block terminator

000051: 2c
image separator:

000052: 01 00
image left position = 1

000054: 01 00
image top position = 1

000056: 16 04
image width = 1046

000058: dc 02
image height = 732

000060: 81
1....... local color table is present
..0...... image is not interlaced
...0..... local color table is not sorted
......001 local color table size = 3*2^(1+1) (4 entries, 12 bytes)

local color table detail: (# indicates BG and TRANS color)
000061: 00 00 00#(000) 00 00 80 (001) 99 cc 99 (002) b0 77 b0 (003)

000073: 02
LZW minimum code size = 2

000074: ff
image data block size = 255
000075: 94 8f a9 cb ed 0f a3 9c b4 da 8b b3 de bc fb 0f 86 e2 f8 0d
000095: e6 89 a6 ea ca b6 ee 0b c7 f2 4c d7 f6 8d e7 fa ce f7 fe 0f
000115: 0c 0a 87 3f 92 f1 88 4c 2a 97 cc a6 f3 09 8d 86 88 d4 aa f5
000135: 8a cd 6a b7 dc ae f7 1b 94 8a c7 e4 b2 f9 8c 4e ab 41 e0 b6
000155: fb 0d 8f cb e7 f4 3a 70 8d cf eb f7 fc be 7f 6d 17 28 38 48
000175: 58 68 78 68 f7 a7 b8 c8 d8 e8 f8 d8 87 28 39 49 59 69 79 69
000195: 08 a9 b9 c9 d9 e9 f9 09 81 29 3a 4a 5a 6a 7a 0a 03 aa ba ca
000215: da ea 2a 86 1a 2b 3b 4b 5b db f6 8a 9b ab bb cb eb 60 fb 0b
000235: 1c 2c 3c ec d2 6b 7c 8c 9c ec 48 cc dc ec fc 6c a9 2c 3d 4d
000255: 5d 0d 05 8d 9d ad bd ed 65 ed fd 0d 1e 6e c1 4d 5e 6e 7e 6e
000275: 23 ae be ce fe 8d fe 0e 1f 5f de 4e 5f 6f 9f 2b 9f af bf 0f
000295: 7c ef ff 0f f0 11 bf 81 04 0b 5e 0a 88 30 a1 c2 34 06 1b 3a
000315: 7c 48 87 02 80 89 14 2b 5a bc 88 31 a3 c6 8d

[skipping 13 data blocks]

003658: 7a
image data block size = 122
003659: 2a aa a3 4a 0d a0 6a aa a7 8a aa a9 aa aa ac 46 aa ad ea aa
003679: bc b0 aa b1 2a ab b3 4a ab 7c fa aa b7 8a ab ab 50 ab bb ca
003699: ab bd ea ab 57 9a ab c1 2a ac 90 f0 ab c5 6a ac c7 8a ac d1
003719: 36 ac cb ca ac 7d 90 ac cf 0a ad d1 ca ab cd 4a ad d5 8a 06
003739: d2 8a ad d9 aa ad 9d 6a ad dd ea ad 50 b0 ad e1 2a ae e3 ea
003759: a7 df 6a ae e7 7a 04 e4 aa ae eb ca ae 68 8a ae ef 0a af 1d
003779: 50 00

003781: 00
image data block size = 0

003782: 3b
trailer - end of GIF file

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On 23 May 2006 13:17:01 -0700 nichughes (AT) mailandnews (DOT) com wrote:

A question relating to http://www.entrust-systems.net/

Your email address, "nichughes (AT) mailandnews (DOT) com", does not work:

<nichughes (AT) mailandnews (DOT) com>: host mail.mailandnews.com[216.51.232.133] said:
550 Mailbox unavailable <nichughes (AT) mailandnews (DOT) com> (in reply to RCPT TO
command)

Who knows how many private replies you've missed.

So two questions. Firstly is this problem appearing elsewhere in other
browsers or other operating systems? I have limited access to different
test platforms so any help would be very welcome. Secondly has anyone
hit this issue before and managed to come up with a solution?

I might suggest doing this purely in HTML and CSS, rather than using an
image at all (especially as big as that image is). My first (untested)
thought is a DIV with green background and 2 extra 50% wide 50% high DIVs
within and positioned to upper right and lower left for the other colors.
Then a big DIV box in the middle.

--
-----------------------------------------------------------------------------

Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ |
(first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------

On 23 May 2006 13:17:01 -0700 nichughes (AT) mailandnews (DOT) com wrote:

Just for a change I have run into a problem that seems to be OS
specific rather than browser specific - the box image that is acting as
a faux border for the main text block shows nasty image effects on the
outside when using either Firefox or Konqueror on Suse Linux. This
image is set to resize with the browser window (and hence the text) and
this seems to be what triggers the rendering problem.

Actually, doing this without an image is easy with tables. But it's
the kind of thing that would drive CSS advocates nuts. I'll let them
show examples of doing it "the right way". So I won't show how to do
it in tables ... unless no one shows how to do it in CSS.

I did try to do it without an image and I was in danger of losing my
sanity over it.

It seems like it should be achievable but in practice the results were
horrible after trying it several ways. Maybe a complete CSS guru could
pull it off but I can't. I could do it with tables but on balance I'd
rather use an image - it degrades more gracefully.

Sorry about the email address: I resorted to that email address a long
time ago after using a "proper" email address on usenet that promptly
got spammed to death. It used to be a valid webmail address, perhaps
they have pulled it due to excessive spam - I have not been very active
on usenet in a while.
---
Nic

A little application of the GIMP has fixed it on my local test version,
so I can put that on the public site next time I do an upload.
As you suggest it was generated by an MS Office application and
anything running on windows seems to handle it just fine - I only
noticed the bug when I tested on a different platform.

Thanks.

--
Nic

On 26 May 2006 02:51:29 -0700 nichughes (AT) mailandnews (DOT) com wrote:

I did try to do it without an image and I was in danger of losing my
sanity over it.

It seems like it should be achievable but in practice the results were
horrible after trying it several ways. Maybe a complete CSS guru could
pull it off but I can't. I could do it with tables but on balance I'd
rather use an image - it degrades more gracefully.

I don't think it would take a guru. But if I get some time, I might go
back and see your page again and give it a shot.

As to tables, I've not run into a degrade issue. Back when people who
promoted newer web standards were coining the phrase "degrade gracefully"
to refer to relatively unstyled results on older browsers when using
newer standards, my table based pages were displaying UN-degraded on the
major older browsers (because that's where I developed things like that).

Sorry about the email address: I resorted to that email address a long
time ago after using a "proper" email address on usenet that promptly
got spammed to death. It used to be a valid webmail address, perhaps
they have pulled it due to excessive spam - I have not been very active
on usenet in a while.

I'm running relatively spam-free, despite my email address being seen
all over the place for years. I use a few DNS blacklists, a blacklist
of my own that is domain name based, and several hundred spamtraps that
let me actively track where spammers are coming from. They tend to
bunch emails for the same host together, so by having spamtraps using
the same hostname, it's fairly easy to detect when it's spam because
they frequently multiple address it to one or more spamtraps at the
same time.

--

---------------------------------------/----------------------------------|
Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
first name lower case at ipal.net / spamtrap-2006-05-30-0403 (AT) ipal (DOT) net |
------------------------------------/-------------------------------------|