Re: [Koha-devel] Item Type Images have various sizes
I see. It would be good to find out how many libraries use the liblime-kids set. I don't think that's really necessary though. The complaints I'm getting from my librarians involve the bridge set. The padding is perfect for the npl set, but not for the bridge set. The images interfere with the location because the padding is not enough to accommodate the image. And it doesn't look good. As nice as it would be to be able to accommodate different sizes of icons, such flexibility is not always the best way to go. In this case we have to consider the use of space in the item cell of the search results table. As I see it the other options are to increase the padding to make room for the larger icons, or have the padding be variable based on the which icon is used for the item type. Increasing the padding would leave excess space around the smaller icons. Having the padding be variable would not be a trivial programming feat in my opinion. Also the item information cells would be a little less uniform in appearance. I'm prepared to increase the padding uniformly to make space for the bridge set. On the other hand I'm not using the liblime-kids set. So it's a small increase. This doesn't seem like the best possible solution to me though. I'm correcting a symptom of the larger problem that the template doesn't know how big the icon is going to be. I would prefer to either have one size of icon or have the item type icons tell the template how much space they need. I'll admit that it is nice to have the larger icons for the kids ( to this end one of my librarians has asked me to increase the font size on the opac ). So, in my opinion, it would be best to have variable padding with the icons. I just don't look forward to trying to code that. I think the best way would be to have it statically set. That way we would save the time it takes to parse the image to find it's width. On Wed, 2009-02-11 at 15:14 -0500, Galen Charlton wrote:
Hi,
On Wed, Feb 11, 2009 at 3:07 PM, Michael Hafen <mdhafen@tech.washk12.org> wrote:
I think it would be best to standardize on a size for these images, so that the css can be set once and look right.
I would prefer that we accommodate different sizes for the icons rather than settle for just one "standard" size. I'm not sure how many libraries are using the liblime-kids set, but the icons in it are larger than npl or bridge to support a common design pattern for childrens' OPACs.
Regards,
Galen -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
I'll admit that it is nice to have the larger icons for the kids ( to this end one of my librarians has asked me to increase the font size on the opac ). So, in my opinion, it would be best to have variable padding with the icons. I just don't look forward to trying to code that. I think the best way would be to have it statically set. That way we would save the time it takes to parse the image to find it's width.
On Wed, 2009-02-11 at 15:14 -0500, Galen Charlton wrote:
Hi,
On Wed, Feb 11, 2009 at 3:07 PM, Michael Hafen <mdhafen@tech.washk12.org> wrote:
I think it would be best to standardize on a size for these images, so that the css can be set once and look right.
I would prefer that we accommodate different sizes for the icons rather than settle for just one "standard" size. I'm not sure how many libraries are using the liblime-kids set, but the icons in it are larger than npl or bridge to support a common design pattern for childrens' OPACs.
Regards,
i agree with Galen here. Michael, i guess the quick-fix for you, is to change your templates/ css for the bridge-set dimensions i wonder if the padding could be changed to a '%' value, rather than a 'px' value... could we have some magical auto-boundary handling here? <li title="" style="margin: 0.4em 0pt; padding: 3px 0pt 3px 30px; list-style-image: none; list-style-position: outside; list-style- type: none; background-image: url(/opac-tmpl/prog/itemtypeimg/bridge/ book.gif); background-repeat: no-repeat; background-position: 0pt 50%;"> Centerville (1)</li>
On Thu, 2009-02-12 at 10:19 +1300, Mason James wrote:
I'll admit that it is nice to have the larger icons for the kids ( to this end one of my librarians has asked me to increase the font size on the opac ). So, in my opinion, it would be best to have variable padding with the icons. I just don't look forward to trying to code that. I think the best way would be to have it statically set. That way we would save the time it takes to parse the image to find it's width.
On Wed, 2009-02-11 at 15:14 -0500, Galen Charlton wrote:
Hi,
On Wed, Feb 11, 2009 at 3:07 PM, Michael Hafen <mdhafen@tech.washk12.org> wrote:
I think it would be best to standardize on a size for these images, so that the css can be set once and look right.
I would prefer that we accommodate different sizes for the icons rather than settle for just one "standard" size. I'm not sure how many libraries are using the liblime-kids set, but the icons in it are larger than npl or bridge to support a common design pattern for childrens' OPACs.
Regards,
i agree with Galen here.
Michael, i guess the quick-fix for you, is to change your templates/ css for the bridge-set dimensions
i wonder if the padding could be changed to a '%' value, rather than a 'px' value... could we have some magical auto-boundary handling here?
<li title="" style="margin: 0.4em 0pt; padding: 3px 0pt 3px 30px; list-style-image: none; list-style-position: outside; list-style- type: none; background-image: url(/opac-tmpl/prog/itemtypeimg/bridge/ book.gif); background-repeat: no-repeat; background-position: 0pt 50%;"> Centerville (1)</li>
Not as far as I know. CSS tends to assume one knows what they are working with before hand. I would move the padding from 30 to 40, which is the quick fix you suggest. For those who use the liblime-kids icon set that would have to be 90. Then, if they also used the npl set, there would be an empty space the size of the icon next to any items that have the npl icon. A percent doesn't really fix that, it's still a static size, just a little less so. What I think would be a good solution, if it didn't mean so much work, would be to have the item type information also have the image width, then that value could be dropped in where the 30 is. There would be no more guessing that way, just have to specify the image width when setting up the icon set. -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
There would be no more guessing that way, just have to specify the image width when setting up the icon set.
yep, this is a pretty doable solution too. i still think there is some CSS fiddle that will make the itemtype- image and the text align happily together Owens' the guy to answer that Q best, round here ;) thoughts Owen?
getitemtypeimagelocation could easily return the subdirectory name as well, allowing a <span class="<!-- TMPL_VAR NAME='iconset' -->"> to wrap the icon. That would allow mixed use of iconsets. I think it's a safe assumption that a given iconset ( subdir of itemtypeimages ) will be uniform in size. -- Ryan Higgins LibLime * Open-Source Solutions for Libraries Featuring KohaZOOM ILS 888-564-2457 x704
On Wed, 2009-02-11 at 17:14 -0500, Ryan Higgins wrote:
getitemtypeimagelocation could easily return the subdirectory name as well, allowing a <span class="<!-- TMPL_VAR NAME='iconset' -->"> to wrap the icon.
That would allow mixed use of iconsets. I think it's a safe assumption that a given iconset ( subdir of itemtypeimages ) will be uniform in size.
One would think so. That is not so in this case. the liblime-kids icon set is mostly 60x60. There are several images that are 90x90 and one that is 62x62. This icon set is not uniform in size, unfortunately for us. Otherwise you have an excellent idea there. -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
I think this is a good line of thought here. Once the icons in the set are all the same size we can easily specify or find out what that size is. Like so. Doing this on my little workstation took about .2 seconds. use GD; $img = GD::Image->newFromGif( "./book-icon-mystery2.gif" ); print $img->width; undef $img; Given 20 search results on a page, and (currently) at most 3 items per results, that's about an extra 6 seconds per page load, worst case. That doesn't seem terrible to me. What do y'all think? On Thu, 2009-02-12 at 14:54 +1300, Mason James wrote:
This icon set is not uniform in size, unfortunately for us. Otherwise you have an excellent idea there.
another idea - perhaps the icon's author's license allow use to resize the icons to a default dimension? -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
Hi, On Thu, Feb 12, 2009 at 10:57 AM, Michael Hafen <mdhafen@tech.washk12.org> wrote:
Given 20 search results on a page, and (currently) at most 3 items per results, that's about an extra 6 seconds per page load, worst case. That doesn't seem terrible to me.
That actually sounds rather expensive to me - six seconds is an *eternity*. ;) I suggest storing the dimensions in the database when an icon is added or assigned to an itemtype or authorized_values, rather than recalculating it every time. Alternatively, the maximum height and width could be stored as an attribute of the iconset. Regards, Galen -- Galen Charlton VP, Research & Development, LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709 skype: gmcharlt
participants (4)
-
Galen Charlton -
Mason James -
Michael Hafen -
Ryan Higgins