Current development on JAMWiki is primarily focused on maintenance rather than new features due to a lack of developer availability. If you are interested in working on JAMWiki please join the jamwiki-devel mailing list.

Comments:Baby Elephant

Underscore issue

I think the issue with underscores in image names is the same issue as Comments:JAMWiki 0.1.3 parsing as an existing link while Comments:JAMWiki_0.1.3 does not - let me know if there's something else going on with images in addition to that problem. I can add this to the list of items to investigate for JAMWiki 0.1.4 - I'm a bit behind at the moment due to work on the search engine, but I'll get back to bug fixes soon (promise!). -- Ryan 09-Aug-2006 16:02 PDT

As to the image going beyond the end of the page, I'll take a look at solving it if no one beats me to it, but there seems to be a lot more people out there with CSS knowledge than there are with good Java skills, so I may leave that to the web design gurus for now ;) -- Ryan 09-Aug-2006 16:02 PDT

I've got the CSS fix for the image dropping below the page.
Add this to the stylesheet:
.clearblock:after {
    content: "."; 
    display: block; 
    height: 0; 
    clear: both; 
    visibility: hidden;
}

/* Hides from IE-mac \*/
* html .clearblock {height: 1%;}
/* End hide from IE-mac */
And in view-topic-include.jsp change <div id="content-article"> to <div id="content-article" class="clearblock"> -- scroco 14-Aug-2006 14:00 PDT
Done, thanks! -- Ryan 14-Aug-2006 14:17 PDT
Perhaps you are correct, it may be the same thing what you've described, I can't tell for sure at the moment. What looked strange to me was the entry in the JAM_TOPIC table which stored the TOPIC_NAME as "Image:baby elephant.jpg" ... I would have expected it to be "Image:baby_elephant.jpg" to match the filename. -- scroco 09-Aug-2006 16:09 PDT
Spaces and underscores have been a bit tricky to handle, and in following Mediawiki's conventions the code simply converts underscores to spaces (except in URLs, where spaces become underscores). There are bugs in a few places where the software doesn't yet recognize that "My Topic" and "My_Topic" are the same topic. It should be easy enough to solve, I just need to take a half hour or so to dig through the code and test things out. -- Ryan 09-Aug-2006 16:14 PDT
Do you agree that for an uploaded file it should keep the filename intact? e.g. keep underscores as underscores? -- scroco 09-Aug-2006 16:21 PDT
I agree that the filename should keep its underscores. When you uploaded your elephant picture that was done - it is on the filesystem right now as "/files/2006/8/baby_elephant-09154915.jpg". I'm not sure that the topic created for that file should have underscores in it though - to this point I've tried to follow Mediawiki conventions, and they convert underscores to spaces. JAMWiki should recognize "My Topic" and "My_Topic" as being the same thing, which will be fixed soon, but I'm not sure if someone tries to create a topic called "My_Topic" that it should be seen as something different than "My Topic". If there is a good argument for making that distinction let me know, but otherwise I'd rather leave it as-is. -- Ryan 09-Aug-2006 16:43 PDT
Yeah, I understand that logic. It's just nagging at me because I feel like a pure topic and a topic which is really a file are two different things conceptually. -- scroco 09-Aug-2006 16:56 PDT
OK, your elephant images on the Baby Elephant page are both working now and the underscore in topic name issue should mostly be resolved, although I need to check the code for any other places I might have missed (the parser code needs to be cleaned up, it's a bit tricky right now). I very much agree that a lot of the Mediawiki stuff is conceptually messed up - some of the inconsistencies in syntax and such are particularly annoying - but I really do want to make it painless to switch between JAMWiki and Mediawiki, so the trade-off is to accept any warts, which seems worth it to me. If keeping underscores as they are is important to you please add an entry on the Bug Reports page noting that converting underscores to spaces should eventually be made a configuration option, and that could definitely be implemented in a future release. -- Ryan 10-Aug-2006 01:23 PDT

On a somewhat related note, should JAMWiki display a warning when a user is uploading a file with the same name as an existing file? If somebody comes along tomorrow and uploads baby_elephant.jpg without knowing that I already uploaded one, it would simply overwrite my version. -- scroco 09-Aug-2006 16:56 PDT

Added to Known Issues#Images. Thanks! -- Ryan 09-Aug-2006 17:12 PDT

Image Resize

As a test, I entered a new baby elephant pic resized to 100 pixels.

  • In the 100px version, the caption is too long, creating an ugly empty space. If the caption is wider than the picture, the caption should break and start on a new line. see Wikipedia elephant pics
In the time it took me to write this up, it looks like you fixed the long caption issue. -- scroco 15-Aug-2006 11:12 PDT
  • Here's the code that is created for the 100px image
<p><a class="wikiimg" href="/wiki/en/Image:baby_elephant.jpg"></p>
<div class="imgthumb imgright">
<img class="wikiimg" src="/files/2006/8/baby_elephant-09164740-100px.jpg"
 width="100" height="96" alt="Baby Chong (Thai word for elephant)" />
<div class="imgcaption">Baby Chong (Thai word for elephant)</div>
</div><p></a></p>
  • Notice the opening anchor tag is encapsulated by a p tag. This actually breaks xhtml rules because the p element should encapsulate the entire anchor element. I see the closing anchor tag is also surrounded by a paragraph element. I think the first closing p tag and the second opening p tag need to be eliminated.
  • It looks like the 100px image is actually another file that was created and placed on the file system. Do you think that's a wise way to go? If I update the image, all the different sizes will get updated too. If I use the same image at 5 different sizes, and update the image five times, that's 25 images created and stored.

-- scroco 15-Aug-2006 11:09 PDT

Paragraph handling has been a huge pain, but I'll try to get the issue above fixed for the next release.
As to different names for different sized files, I'm not sure how else to handle that - the alternative would be that if someone uploads high-res versions of files (which is the norm for Wikipedia and Wikitravel) and we just rely on the browser to resize the image that a page with five images could be downloading several megabytes worth of data. If we use a single image name such as "baby_elephant-09164740-resized.jpg" then there would be no way to cache a thumbnail version for one page, and a 200px version for another page. I agree that it could potentially lead to a lot of different images being stored, but I guess I see that as a lesser of two evils. Any alternative suggestions would be welcome. -- Ryan 15-Aug-2006 11:27 PDT
The XHTML paragraph issue is hopefully fixed now. In addition, the image caption is no longer a link, which is how Mediawiki handles images. -- Ryan 15-Aug-2006 21:54 PDT

I think something like "baby_elephant-09164740-resized.jpg" would work fine. The browser caches the image itself, not the size of the image. So if pages include that image file at different sizes, it will indeed be cached for both, and simply rendered at different sizes. You'd just need to choose an intelligent size for the "-resized" version of the image, not too big, not too small. -- scroco 15-Aug-2006 11:40 PDT -- Actually, upon further thought, this is even better, because the -resized image would be cached for all possible sizes, whereas one file per size means you download a new image for each different size -- scroco 15-Aug-2006 11:45 PDT

That sounds reasonable. Rather than just "resized" I think it might be better to provide a configurable param so that a site admin could choose his preferred increment for determining when to cache a resized version - I'm imagining something like an "image cache increment", where -1 would indicate "do not ever cache a resized image" and "600" would indicate "cache images in increments of 600 pixels". Thus if the increment is specified as 600, any request for that image smaller than 600px (example: [[Image:Foo|500px]]) would return the 600px version. A request for the image sized between 600 and 1200 pixels would return the 1200 pixel version. The default could be set at something like 450px, which should provide a nice balance since thumbnails tend to be smaller than that size, and full images are usually around 600-800 pixels. Would that work? -- Ryan 15-Aug-2006 12:32 PDT

Yeah, that sounds good. Of course, be sure to always use the original if it is less than the admin-specified increment. Or perhaps even better, you could make it so that if the original is less than some size (say 400), then always use the original? Also, I'd enforce some kind of minimum increment (say 50). I wouldn't want a clueless admin to specify 5 as the increment level. -- scroco 15-Aug-2006 13:35 PDT

OK, I've taken a stab at implementing this functionality. It works in the limited testing I've done, but if you notice any problems please let me know. The minimum increment value isn't there yet, but I'll add that to the Known Issues list. -- Ryan 15-Aug-2006 23:31 PDT

Caption ending in a link

I'll look at what's going wrong with [[Image:Foo|Test [[Link]]]]. Thanks for testing. -- Ryan 16-Aug-2006 15:30 PDT

Hopefully that helped - regular expressions have never been my strong suit. -- Ryan 16-Aug-2006 15:44 PDT

Yup, that helped. Look at the first image on that page, it's actually an image with an image inside the caption.

[[Image:baby_elephant.jpg|frame|outer recursive image [[Image:baby_elephant.jpg|inner caption]] caption]] 

-- scroco 16-Aug-2006 15:48 PDT

That's one of the things I like about open-source - working for a company, it's up to me to test code. With open-source I release something that works well enough and let other people come up with weird and twisted testing scenarios like that one ;-) -- Ryan 16-Aug-2006 15:51 PDT