Web galleries and HTML

Took a quick look at quite a configurable web gallery generator
just now, it was praised either here or on a Mac group recently:
JAlbum.app

It was nice that one could change the css but the engine
generating the HTML was not well informed. I suspect if the
author had hung around here a while, he would have made a really
good product. No complaints of course, it is not commercialware.

What I do wonder though is when someone makes such an app, where
does he or she get the image rendering algorithms, like resizing,
compressing etc, are they open source? And are they easily made
to be as good as in PS or FW?

--
dorayme

dorayme

On Tue, 19 Sep 2006 10:36:42 +1000, dorayme wrote:

> What I do wonder though is when someone makes such an app, where does he
> or she get the image rendering algorithms, like resizing, compressing etc,
> are they open source? And are they easily made to be as good as in PS or
> FW?

There are open source libraries/modules for these things. A number of
languages have bindings for image magick. I often use it in Perl and
I like it a lot.

Gimp is programmable with Scheme, Perl, and several other languages.

What is your generator in? What does it say to use/include/load at the
top of the source code?

In article <> ,
mbstevens <> wrote:

> On Tue, 19 Sep 2006 10:36:42 +1000, dorayme wrote:
>
> > What I do wonder though is when someone makes such an app, where does he
> > or she get the image rendering algorithms, like resizing, compressing etc,
> > are they open source? And are they easily made to be as good as in PS or
> > FW?
>
> There are open source libraries/modules for these things. A number of
> languages have bindings for image magick. I often use it in Perl and
> I like it a lot.
>
> Gimp is programmable with Scheme, Perl, and several other languages.
>
> What is your generator in? What does it say to use/include/load at the
> top of the source code?

I don't have access to the programming code in this app... I just
downloaded it and took a look. JAlbum.

Be nice to be able to configure the html as well as the css. The
css is easy as it is one file and applies to all. But the html
are as many files as there are pics and to control that would
need either parameters that non programmers can use or else the
source code. It may be available and I don't know it.

Is there anything out there that actually generates simple non
table based mark up. It would be nice not to have to make albums
"by hand" as I always seem to end up doing! I now particularly do
not like fixed layouts for thumbnails (the strong dislike has
stemmed from seeing that url you kindly provided about floating
divs for thumbnails), I like very much now, the idea of thumbnail
wrapping and regard fixed rows and cols for these things as a bit
dumb. The point of being able to control the html is to be able
to control the css that applies to it. With JAlbum, one can only
style a table based set of files. (Sure, it's better than a slap
in the face with a wet fish.)

--
dorayme

On Tue, 19 Sep 2006 12:45:52 +1000, dorayme wrote:

> In article <> ,
> mbstevens <> wrote:
>
>> On Tue, 19 Sep 2006 10:36:42 +1000, dorayme wrote:
>>
>> > What I do wonder though is when someone makes such an app, where does
>> > he or she get the image rendering algorithms, like resizing,
>> > compressing etc, are they open source? And are they easily made to be
>> > as good as in PS or FW?
>>
>> There are open source libraries/modules for these things. A number of
>> languages have bindings for image magick. I often use it in Perl and I
>> like it a lot.
>>
>> Gimp is programmable with Scheme, Perl, and several other languages.
>>
>> What is your generator in? What does it say to use/include/load at the
>> top of the source code?
>
> I don't have access to the programming code in this app... I just
> downloaded it and took a look. JAlbum.
>
> Be nice to be able to configure the html as well as the css. The css is
> easy as it is one file and applies to all. But the html are as many files
> as there are pics and to control that would need either parameters that
> non programmers can use or else the source code. It may be available and I
> don't know it.
>
> Is there anything out there that actually generates simple non table based
> mark up. It would be nice not to have to make albums "by hand" as I always
> seem to end up doing! I now particularly do not like fixed layouts for
> thumbnails (the strong dislike has stemmed from seeing that url you kindly
> provided about floating divs for thumbnails), I like very much now, the
> idea of thumbnail wrapping and regard fixed rows and cols for these things
> as a bit dumb. The point of being able to control the html is to be able
> to control the css that applies to it. With JAlbum, one can only style a
> table based set of files. (Sure, it's better than a slap in the face with
> a wet fish.)

If it is open source you should be able to get into it and modify things.
Or find one that is open source and modify it to write better HTML. If
it's in Perl, Ruby, or Python it won't be too difficult. I did exactly
that to two different Perl programs to generate the 300 some-odd
interlinked genealogy pages at my site from simple gedcom files.

(But I don't recommend image-album-creators unless all your images can be
treated exactly the same way. Often it is a better idea to hand-tweak
images. You can cut download time by about 2/3 for some .jpgs, for
instance, without it being noticeably degraded to a human viewer. Others
can hardly be reduced at all. It's all a matter of hand tweaking while
watching the test files. And choosing the right size and cropping for a
thumbnail of a full image is also a human intensive task if it is to be
done right.)

In article <> ,
mbstevens <> wrote:

> > I don't have access to the programming code in this app... I just
> > downloaded it and took a look. JAlbum.
> >
>
> If it is open source you should be able to get into it and modify things.
> Or find one that is open source and modify it to write better HTML.

The one I mentioned is compiled with no access as far as I can
see... but in another 4 weeks (unless flooded with more work), I
will look into your other suggestion)

--
dorayme