The simple answer: You must allow the xml file to be cached.

This could be a security risk in the situation where the chart data is sensitive. IE7 still suffers from this problem however.

Not only should the flash file itself “charts.swf” be cached, but the XML file used to generate the file needs to be cached as well.

All you need to do is remove any type of “no-cache” headers that are sent for those two files.

Cache-Control: no-cache #=> remove this line (http 1.1)
Pragma: no-cache #=> remove this line as well (if present - http 1.0)

There is a solution though that can still retain some security: limit the cache time to a few minutes or seconds.

That way if the user logs out from a public terminal, the cache would expire shortly — so the next user of the public terminal should not be able to see the chart data by hitting the back button or viewing the cache on the hard-drive.

Cache-Control: max-age=0

More info can be found about Cache-Control HTTP headers from the official spec.

Everybody says “ATI sucks on Linux”…I had a difficult time with Nvidia, so I decided to try it. I found it difficult to get it working, but thanks to some great resources, and a few spare hours on Friday night it works!

Be sure to backup your original xorg.conf file in the case of a major foul up… ‘mv xorg.conf xorg.conf.pre-ati.orig’

First, you need to get the ATI proprietary drivers installed, which suprisingly was relatively painless following this ATI Ubuntu guide.

Be sure to test your results with the ‘fglrxinfo’ command. if you did not get something like this, then go back…because you probably made a mistake.

Make sure you make the required xorg.conf changes described above (read through it a few times first, you’ll save yourself a headache if you try to skim through).

“Method 1″ worked fine for me…short of breaking kde-guidance…which now gives me an “orphaned command module” error.

$ fglrxinfo
display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: Radeon X1650 Series
OpenGL version string: 2.0.6334 (8.34.8)

After doing that, you may need to do some manual modifications of xorg.conf. Most of the xorg.conf file generated by the ATI driver install mentioned above puts all the Identifiers as “aticonfig-SECTION[0]” where “SECTION” refers to one of “Monitor, Screen, or Device”.

One thing I was disgruntled with was that the above ATI driver installation broke kde-guidance pkg…the “Monitor and Display” interface for “Control Center” in KDE.

This was a bit tiresome trying to fix, so I gave up and figured out to change all resolutions in the following files to reflect 1440×900. I couldn’t find any good info on “orphaned command module” errors…so I gave up and continued to manually change my settings…

$ cd ~/.kde/share/config
$ grep -rl '1440' .

#I inspected them all, but the potential culprits were:
./kdeglobals
./systemsettingsrc
./displayconfigrc
./khelpcenterrc
./kinfocenterrc
./kcontrolrc

Definitely, change ./displayconfigrc, as I believe that is what gets written when you modify your desktop display settings. The others were mostly default window sizes, which you can always adjust once you log back in to the desktop.

The follow block is near the top of xorg.conf and is where you set the defintions to be used. In theory, you could simply add new configurations to the file without deleting your old (and is probably a good idea). I eventually deleted all my old junk since I already made a hardcopy of the entire file.

This portion should have been generated for you in the ATI installations steps to follow mentioned earlier.

Section "ServerLayout"
        Identifier     "Default Layout"
        Screen      0  "aticonfig-Screen[0]" 0 0
        InputDevice    "Generic Keyboard"
        InputDevice    "Configured Mouse"
        InputDevice    "stylus" "SendCoreEvents"
        InputDevice    "cursor" "SendCoreEvents"
        InputDevice    "eraser" "SendCoreEvents"
EndSection

The chain of command goes something like:

ServerLayout -> Screen -> Monitor (and/or Device)

..as far as controlling which Sections to load in xorg.conf by default (it finally started to make sense!).

Below is my relevant “Screen” section:

Section "Screen"
        Identifier "aticonfig-Screen[0]"
        Device     "aticonfig-Device[0]"
        Monitor    "aticonfig-Monitor[0]"
        DefaultDepth     24
        SubSection "Display"
                Viewport   0 0
                Depth     24
                #16:9 aspect ratios
                Modes   "1440x900" "1366×768" "1280x720" "1024x576"
        EndSubSection
EndSection

Above I added the “Modes” that my monitor would support. This gives us somewhat of a strict control over what Xorg will do…and without it, good luck finding the menu, because mine was off screen at 1980×1400 or something.

In the event your screen or desktop is “hosed”, always remember “ctrl+alt+delete (or backspace)” will dump you back into the console…so you can re-edit xorg.conf.

You can use the handy command-line utility ‘gtf’ to generate the proper Modelines for xorg.conf for the desired resolution (see: ‘man gtf’ for more info):

$ gtf 1440 900 60

  # 1440x900 @ 60.00 Hz (GTF) hsync: 55.92 kHz; pclk: 106.47 MHz
  Modeline "1440x900_60.00"  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync

This goes in the relevant “Monitor” section in xorg.conf. I’m not entirely sure if this is necessary. I read somewhere that it is used to override auto-detection, so I figured put it in anyway.

Below is my relevant xorg.conf “Monitor” section with a few modifications:

Section "Monitor"
        Identifier   "aticonfig-Monitor[0]"
        Option      "VendorName" "ATI Proprietary Driver"
        Option      "ModelName" "Generic Autodetecting Monitor"
        Option      "DPMS" "true"

        #Option     "Preferred Mode" "1280x720_60"
        #Option     "Preferred Mode" "1368x768_60"
        Option      "Preferred Mode" "1440x900_60"

        # gtf => 1280x720 @ 60.00 Hz (GTF) hsync: 44.76 kHz; pclk: 74.48 MHz
        # Modeline "1280x720_60.00"  74.48  1280 1336 1472 1664  720 721 724 746  -HSync +Vsync

        # gtf => 1368x768 @ 60.00 Hz (GTF) hsync: 47.70 kHz; pclk: 85.86 MHz
        #Modeline "1368x768_60.00"  85.86  1368 1440 1584 1800  768 769 772 795  -HSync +Vsync

        #gtf => 1440x900 @ 60.00 Hz (GTF) hsync: 55.92 kHz; pclk: 106.47 MHz
        Modeline "1440x900_60.00"  106.47  1440 1520 1672 1904  900 901 904 932  -HSync +Vsync

EndSection

One thing I am unsure of is running at something smaller than 1440×900 and still use the entire screen dimensions of the monitor. When I tried doing this, I lost screen space….”black bars” on left and right, top and bottom.

Update: Ironically, after I got it all squared away and running, as I finish writing this post I went back to check the verbage for the kde-guidance error, and it now works!. Resolution is still at 640×480 but I won’t mess with that, it is obvious incorrect.

Of course there are “excuses” for inline CSS style declarations…that’s why we have them.

Are they misused? Of course.

HTML emails need to be constructed with inline styles…for those who have never tried….but alas, that is not why we have ‘em.

We have them to override those “special one-off” cases that do not require a global definition.

Use the “DRY Principle — Don’t Repeat Yourself”

1. If you need an inline style, use it.
2. If you re-use it on that page only, put it in the local stylesheet.
3. If you use it on multiple pages, refactor it into your global css file.

There was no mention of “specificity” — which may be considered part of the cascade.

/* generalized style -- less specific */
ul { background-color: green; font-weight: bold; }

/* overrides more general styles -- but also inherits */
ul#nav.special { background-color: red; }