GNOME Bugzilla – Bug 319933
Suggested enhancements to web exporter template language
Last modified: 2006-11-13 19:13:29 UTC
1. Changes to how image captions are handled by the web exporter - Change <gthumb:comment> to only output the image comment (not place or time). This will allow greater flexibility in formatting. - Add <gthumb:place> and <gthumb:date_time> to output image place and time, behaving exactly like <gthumb:comment>, and add checkboxes for "Place" and "Date and time" to the web exporter's Image Caption and Thumbnail Caption dialogs. These will be necessary to support the above change. 2. Changes to how index pages are generated by the web exporter - Add an option to use a single, long index page to the web exporter dialog; if enabled, the "rows" droplist is disabled and <gthumb:table> outputs as many rows of the specified number of columns as necessary. - Added a new tag <gthumb:thumbs> to output thumbnails into an image page without the surrounding table structure; this is suitable for templates that arrange thumbnails with CSS or JavaScript without using tables. 3. Changes to the parsing of web album templates - Modify expression parsing in web album generation to allow quoted expressions and string constants containing spaces. 4. Changes to how header and footer text is parsed by the web exporter - Re-write libgthumb/comments.c:_append_excaped_text_for_html() to not replace escaped characters (preceded by a backslash) with HTML entities - this allows HTML markup and other entities such as "©" to be used in footers (written as "\©". 5. Other changes to the web album template language - Add a new read-only boolean variable to the web album template language ("copy_originals"), true if original images are to be copied to the album directory. This will allow templates to insert links to original images only if they are present. - Add "alt" and "id" attributes to <gthumb:image>.
Created attachment 53931 [details] [review] Patch against gthumb-2.6.8 This patch provides the requested functionality to gthumb 2.6.8, and updates doc/theme-xml.txt to reflect the changes.
Created attachment 54170 [details] [review] Patch against gthumb 2.6.8, version 2 Fixed a heap corruption bug (that typically caused a segfault) in the original patch
*** Bug 150222 has been marked as a duplicate of this bug. ***
Created attachment 76065 [details] [review] exporter enhancements, version 3 Here's my updated patch. It's not really as big as it looks, because albumtheme.c and lex.albumtheme.c are generated from albumtheme.y and albumtheme.l using bison and flex. The good way to parse export templates would be to simply require them to be valid XHTML and use an XML parser, but I don't have the required time or knowledge of XML, so I stuck with modifying the current "tag soup" parser - hence the bison and flex stuff. Besides the functionality described above, I added support for non-ascii characters in headers, footers, comments, and places. Any character that isn't printable ASCII is now escaped as a decimal HTML entity. It's also now possible to put escaped HTML markup in comments and places; although gthumb won't parse this internally, it will work when exported to web pages. This should solve bug 155042. Rennie
Created attachment 76066 [details] Test case: DHTML export template Here's a template designed to make use of the export template language changes requested in this bug. (Or rather, here's the template that the changes requested in this bug were designed to support.) It's loosely based on the existing "Classic" template, updated to XHTML 1.0 Strict, with a lot of CSS improvements and JavaScript to dynamically determine the optimal screen layout when a page is displayed. There's also more JavaScript to correct rendering errors on various common web browsers as of last fall; I haven't tested it against MSIE 7 or the latest versions of Opera. This template will create web albums like this: http://pages.cpsc.ucalgary.ca/~degraaf/Photos/pumpkin_carving_2006/ (no index captions) or this: http://pages.cpsc.ucalgary.ca/~degraaf/Photos/aurora_borealis/ (with index captions). If you want, feel free to add this to CVS, too. Rennie
Rennie, Great stuff! I'm starting my tests of the main patch. I'll look at the fancy template later. Some minor issues so far: 1) I'm not quite satisfied with the "Use a single index page" label. Maybe this should be be something like "or no limit to number of rows", to tie it more closely to the "Rows" box. Perhaps the "Columns" box should be first, then the "Rows" box, then a "or no limit to number of rows" override. 2) The spacing between options in the "Caption" section of the "Thumbnail Caption" and "Image Caption" dialogs is different than in the "Photo data" section. 3) Maybe the "Caption" section of the above dialogs should be renamed "User Comments" - "caption" seems redundant. And perhaps the "Photo Data" section should be renamed "Exif Photo Data", or "Camera Data". What do you think? 4) Unnecessary commented-out lines at patch lines 4508, 4534, and maybe elsewhere. I don't think they serve any purpose. I'll keep testing... I can fix these issues later, or you can, whoever does it first is fine... - Mike
*** Bug 155042 has been marked as a duplicate of this bug. ***
Another issue: /apps/gthumb/dialogs/web_album/single_index wasn't added to data/gthumb.schemas.in. - Mike
I have a patch coming in the next hour to address my concerns listed above. - Mike
I have committed the patch above (with minor UI tweaks, please have a look) to simplify development. I have found one major issue: The "return to index" link (when viewing a single photo) is not functioning correctly in the "single index page" mode. It is always referencing "page002.html", which does not exist. Please look into that, Rennie. - Mike
(In reply to comment #6) > 1) I'm not quite satisfied with the "Use a single index page" label. Maybe this > should be be something like "or no limit to number of rows", to tie it more > closely to the "Rows" box. Perhaps the "Columns" box should be first, then the > "Rows" box, then a "or no limit to number of rows" override. The problem with a label like that is that if the template using <gthumb:thumbs> to generate the index page(s), rather than <gthumb:table>, then the number of "rows" and "columns" on a page is determined by the template itself (via CSS or something), rather than by gthumb. Currently, if "single index" mode is off, then using <gthumb:thumbs> will output (rows * cols) thumbnails on each index page, but the layout is up to the template. If we're going to change the labels, we should try for something that makes sense in all modes. Unfortunately, we can't change the dialog based on which type of template is being used, since gthumb doesn't know anything about individual templates when displaying that dialog. > 2) The spacing between options in the "Caption" section of the "Thumbnail > Caption" and "Image Caption" dialogs is different than in the "Photo data" > section. Sorry; I'd thought that I'd fixed that. > 3) Maybe the "Caption" section of the above dialogs should be renamed "User > Comments" - "caption" seems redundant. And perhaps the "Photo Data" section > should be renamed "Exif Photo Data", or "Camera Data". What do you think? I'd reccomend against adding the word "Exif" there - we're just trying to convey the information from the Exif tags, not describe where we got it. Someone could easily extend the comment file format to include similar data for the benefit of pictures that don't have Exif tags attached, in which case putting the word "Exif" there would be misleading. "Camera Data" is fine by me, although I think that "Camera Settings" might be more descriptive. > 4) Unnecessary commented-out lines at patch lines 4508, 4534, and maybe > elsewhere. I don't think they serve any purpose. They are a relic of me considering to disable both the rows and columns spinbuttons when in single index mode, which I evidentally forgot to remove. You are correct that they served no purpose. (In reply to comment #8) > /apps/gthumb/dialogs/web_album/single_index wasn't added to > data/gthumb.schemas.in. What does that file do? Something to do with gconf? (In reply to comment #10) > I have committed the patch above (with minor UI tweaks, please have a look) to > simplify development. Thanks! > I have found one major issue: The "return to index" link (when viewing a single > photo) is not functioning correctly in the "single index page" mode. It is > always referencing "page002.html", which does not exist. I'm on it. Rennie
Created attachment 76127 [details] [review] Fix for broken index links This should fix the broken issue with index links. It's amazing what a single bit can do, isn't it? By the way, I discovered that the "return to index" links are always broken in pages generated using the template that I linked as a test case, because of a bug in the template code. I'll post a fix if you want it. Rennie
Rennie, Thanks, I'll test & apply the patch later today! Yes, please upload a corrected template. I do plan to review it as well - I just haven't had time to touch it yet. I have to think about the row/col/single mode labeling issue more... - Mike
OK, the patch has been committed. Also, "sort by comment" was added yesterday (bug 356718) - so when testing, please try that mode too! Regarding data/gthumb.schemas.in: I believe that tells gconf about the registry scheme gthumb uses. Run gconf-editor to see the keys that gconf is aware of. I'll revisit the CSS/row/UI issue after you upload the correct template, so I can "learn by doing". - Mike
Rennie, Can you upload the corrected template in a patch format, with the appropriate Makefile updates? Thanks! - Mike
Created attachment 76161 [details] [review] DHTML export template (v2) Here's the fixed version of the export template, with updates to the makefiles. Be advised that there is binary data in the patch (PNG images). If you have any issues with it, let me known and I'll upload a tarball of the new files. Rennie
Created attachment 76173 [details] Screenshot of odd BestFit spacing That's a pretty nifty template, Rennie. The index pages are great! The image pages could use some tweaking. See my attached screenshot. There is a lot of unused space on the left, but text is falling off the edge on the right. Can you improve the panel auto-sizing? I still have to think about the row/col UI. - Mike
The BestFit album has been committed, to simplify further tweaking. - Mike
Created attachment 76179 [details] [review] possible album UI Rennie, Here's a possible Glade file for the album generator UI. Basically I refer to the single index mode again, and add a note about #rows and #columns not being fixed for some styles, but row * column is constant. I thought we could possibly add a line below the row box saying "for a total of XXX images per page", where XXX would be updated when you changed the row or column values - but I ran out of time and maybe it's silly anyway. What do you think? If you like it, or modify it a bit, patch it into your next diff. Thanks! - Mike
Created attachment 76195 [details] Screenshot of correct BestFit spacing (In reply to comment #17) > Created an attachment (id=76173) [edit] > Screenshot of odd BestFit spacing > > That's a pretty nifty template, Rennie. The index pages are great! > > The image pages could use some tweaking. See my attached screenshot. There is a > lot of unused space on the left, but text is falling off the edge on the right. > Can you improve the panel auto-sizing? The empty space on the left is intended for the comment, place and date, if you have set them for the image. You're correct that the layout looks a little lopsided if none is present, but shifting the main picture over to the side when no comment is present would be difficult. This would also mean that albums containing pictures with and without comments would switch between two apparent layouts. It would also look lopsided if a user chose to include comment data, but no camera settings. My design philosophy for this template was that the picture is the most important component, and should be centered on the screen and as large as possible. Since most people's screens are wider than they are high, and many pictures are vertical, I opted to put picture metadata in columns to the left and right. The header and footer are constant height (80 px each), the left and right columns are proportional width (20% each), and the center panel gets the rest; the picture is dynamically resized to fit the center panel as well as possible. You can see the basic outline at http://pages.cpsc.ucalgary.ca/~degraaf/test/foo.html. Regarding the text overflowing to the right of the screen, are you using an override on page-specified font sizes? In Firefox 1.5, I was unable to reproduce the effect seen in your screenshot until I jacked the minimum font size up to 22pt. What appears to be happening is that the minimum line width (I'm not sure if the browsers aren't smart enough to insert line breaks inside words, or HTML specifies not to) is wider than the available width (20% of the screen width, less a few pixels of padding). So it overflows to the right. I can stop this from happening by using the 'overflow' and 'clip' CSS attributes to simply not display overflowing text, but I'm not sure that that's any better. (What do you think?) I might be able to make more space to the left using some JavaScript trickery, but it'll probably be a few days before I have time to try that. Of course, that will limit the available space for the picture. I attached a screenshot of what an image page is "supposed" to look like, using Firefox 1.5 with default font settings at 1280x1024. I like your proposed change to the export UI as it is, except that I would change the word "styles" to "themes", for consistency in terminology. I think that the description that you added is a suitable balance between unclarity and unnecessary verbosity; users can refer to an external help file if they want more detail. (On that note, someone should fill in section 12.8 of the help file. It's pretty sparse.) Of course, I'm hardly a UI expert - you're lucky if you get an interactive command prompt from most of the software that I write. Rennie
Rennie, Thanks for the clarifications. That makes sense. My particular test case used photo re-sizing to 320x200 (and text-size overrides with Firefox 2.0 - I hate small text). Is it possible to reduce the 60% photo-column width when that results in more pixels than the width of the photo? (I don't know much about CSS, so forgive me if I ask for the impossible...) For wide photos, I think the text overflow should be left as-is. I can still scroll to see it. Not that many people use font overrides as large as I do. - Mike
The UI tweak was committed to CVS HEAD. - Mike
(In reply to comment #21) > My particular test case used photo re-sizing to 320x200 (and text-size > overrides with Firefox 2.0 - I hate small text). Is it possible to reduce the > 60% photo-column width when that results in more pixels than the width of the > photo? (I don't know much about CSS, so forgive me if I ask for the > impossible...) I don't think that I can do that with CSS, but I should be able to do it with JavaScript. I'll see what I can do. Rennie
Created attachment 76254 [details] [review] Fix for BestFit spacing Here's a fix for the spacing issue. In the JavaScript, I check if the camera settings table is overflowing to the right; if it is, and if the picture isn't using up all of its available space, then I move the settings table to the left. I tested the new version on Firefox 1.5, Konqueror 3.5.5, Opera 8.54 and Opera 9.02. I don't have any MS Windows systems handy to test MSIE 6 or 7. I discovered that Opera 8.54 has a minor problem rendering index pages - it puts the footer immediately below the thumbnails, rather than at the bottom of the screen - and Opera 9.02 adds to this problem by messing up the link areas on the bottom row of thumbnails. I could probably compensate for the footer alignment issue with JavaScript, but I don't know what I can do about the link issue. Firefox and Konqueror behaved as I expected. While I was at it, I changed all the copyright notices at the top of the files to the FSF - this is supposed to be GNU software, after all. Rennie
Very nice! Patch committed. I'm happy as long as it works on Firefox, personally, but I will test it on IE later. Then we can probably mark this bug as "fixed". Browser tweaks can be reported later, if anyone figures them out. Rennie, can I have your opinion at http://bugzilla.gnome.org/show_bug.cgi?id=370013#c11? - Mike
Looks OK on IE6, except for IE's lack of transparent PNG support (navigation arrows). Closing bug. Thanks for all your work, Rennie!
(In reply to comment #26) > Looks OK on IE6, except for IE's lack of transparent PNG support (navigation > arrows). Right; I forgot about that. I have non-transparent copies of those PNGs lying around somewhere, if you'd like them. > Thanks for all your work, Rennie! And thank you for your time and efforts. (Now I can remove my outdated patches and grumbles about being ignored by the gthumb maintainers from my web site.) Rennie
I guess non-transparent PNGs would be friendlier, although people who use IE6 are bad people. Shrug. :-) I'm not the maintainer... you are still being ignored by the maintainer :-) I was frustrated by some aspects of gthumb, so I developed some patches to fix my own troubles, triaged a huge backlog of bugs, and made enough noise to be granted cvs access. My request for the ability to package new releases was turned down, though :-( Anyway... got any other nifty gthumb tricks up your sleeves? - Mike
I have greatly expanded the web album section of the manual in CVS HEAD. Please have a look. - Mike
Rennie, Could you cc yourself to bug 361913 and have a look at Jef's latest patches? - Mike
Created attachment 76506 [details] [review] Minor tweaks to web exporter help file (In reply to comment #29) > I have greatly expanded the web album section of the manual in CVS HEAD. Please > have a look. Thanks - that looks good. I made a few minor changes, and expanded the paragraph on header and footer generation. Please review at your leisure. Rennie
Thanks! Patch committed with minor spelling correction ("litteral"). - Mike