Short description
On some themes I only use a logo banner image for the title/logo. This should also be resized by the browser width.
Currently I solve this by an extension of the common.js by
function resize_image(which, max) {
var elem = document.getElementById(which);
if (elem == undefined || elem == null) return false;
if (max == undefined) max = document.body.clientWidth;
if (elem.width > elem.height) {
if (elem.width > max) elem.style.width = max + 'px';
} else {
if (elem.height > max) elem.style.height = max + 'px';
}
}this solution is based on http://atomgiant.com/2006/05/30/resize-images-with-javascript/
and an image definition, e.g.
<img id="logo_image" onload="resize_image('logo_image')" src="/moin_static183/banner.png" alt="banner">
if we can get the browser width on each request we maybe can use the Image class to shrink the size and to cache the new sized banner.
I do not like this feature for a default moinmoin theme very much, reasons:
it is not used for a default theme and we don't plan to use it for a default theme
- resizing images only in width are mostly useless because if you have a logo you also need to resize in the height and then you get "lost" with a too big header.
that special theme has nothing else than a banner
- from the usability viewpoint you gain nothing! if you start to resize something depend on the browser screen you may want to start to resize the fonts, icons, etcetera
no, you just want to have it on each screen in full width
- resizing can leads to other problem because you have screen width from 160px (mobilephones) [get's too small] to 2048px (dtp screens) [ugly because of too much resizing]
depends on the image
I personally do not like to use javascripts to tweak some layout stuff; images with css (% for width and use max-/min-width or just using background images is maybe the cleaner solution). well just IMHO bye -- MarcelHäfner 2009-04-30 17:10:13
Do you have a better idea how to fix the default width of EmbedObject for pdf documents to fit on different screens? You can't use % .
-- ReimarBauer 2009-04-30 23:00:55 why we can't use 100%; I just changed the EmbedObject.py to default width=100% and in my Opera (linux), firefox 3 (linux; acroread 9.1.0 and windows) it works.. http://www.wikiwiki.ch/EmbedObject?action=AttachFile&do=view&target=RPfeifer_kl.pdf
You did it only for width in the example page http://www.wikiwiki.ch/EmbedObject you use a width and height of 800px and for do=view a width of 100% and a height of 800px. -- ReimarBauer 2009-05-26 08:49:09
cool to see this issue fixed. That didn't worked in the past. I will try later
- but well, if this not working with the common browser and plugins, then for sure you need to have some javascript to get the max. width and then resize it (but this is would be more a workaround to a not correct working plugin, I think so)
yeah me thinks it is only a workaround until there is a better plugin available or we can use different mimetype for representation
Note about embedded files:
- we had also very bad experience with embedded pdf files. mainly because if you have big pdf's (around 5 or 10mb) then it takes somtimes quite a long till the pdf will be displayed... for the user this is very "unlovely" because the only feedback he receive (while downloading the file) is the mouse icon and nothing else.
we have had that not only with embedded pdf files. That big adobe extensions behaves sometimes very strange. Often you have half of a zombie process left over which needs nearly 100% of your CPU for whatever it is doing.
- another point is that this pdf plugin from adobe can hang from time to time and then you have to close the browser and reopen (this happens specially when you download a big file). I had this problem by myself on firefox and sometimes also on ie7. for only viewing small/normal pdf files there is not so much trouble, sure it depends if you use it in your intranet (faster speed) or over an umts/grps connection (slower speed).
For sure we need another better plugin or a different mimetype. I prefer currently for this case pdf2svg. Or to formulate it a bit different. There are lot's of mimetypes and less plugins. We have two ways: user has a plugin or we use a format that the browser can render. May be instead of requiring a plugin for some mimetypes we could also use a svg representation see ConvertibleFormats and offer another link for the original (pdf) view. Or to give another example instead of requireing lot's of media(player) extensions we could convert them to e.g. to swf to represent presentations, audio and video files. We have to discuss for 2.0 the UI for that what is currently named AttachFile. That should not be done on this feature request page.