New Year – New Story

Entering 2023 we have just released a new major version of Story skin. Story skin is known for its ability of producing page layouts with mixed content – text blocks, thumbnails, larger images and subfolders – in an exciting way. Now we have made the experience even smoother by adding new thumbnail layouts, new barebones styles, and improving the mobile experience further. Here are the highlights.

New Plain white, and Plain dark styles

1. New styles

Story skin traditionally had a few styles, that all had the same large banner – the so-called “hero” – at the top. Now we wanted to show off the skin’s versatility, thus reworked all the styles – using different hero arrangements, tuning down the harsh colors –, and dropping 3 new simple styles into the mix; “Plain dark”, “Plain white” and “Smooth”.

2. Mobile usability

jAlbum has its roots in the desktop era, but over time it gradually evolved to support mobile interfaces. Hence, its skins have inherited some mouse-native behaviors; like clicking an image takes you to the next image. Today, on mobiles, we use the swipe gesture to achieve the same. Story skin has been using the swipe gesture for navigating images, but using single-click for toggling the lightbox navigation and caption, and double-click for toggling the zoom is new.

Related setting: Settings / Story / Lightbox / Click action

3. New thumbnail layouts: justify and patchwork

Up to now, Story skin has offered 2 thumbnail layouts: “fixed grid” and “masonry”. Fixed grid is the old-school, table-like arrangement, while masonry is a horizontal, brick-like layout. This latter was laid out by the browser, using various CSS tricks to achieve the justified look. Unfortunately, browsers are not always capable of doing that – sometimes leaving gaps around the columns –, so we have added the new, javascript-driven “justified” layout, which always ensures the columns reach both the left and right edges. The script is also capable of changing the individual rows’ heights, therefore clipping of images almost never happens. This layout looks so much better than masonry, and behaves good enough so far, we might remove masonry one day.

The other new layout is the so-called “patchwork”, which varies the thumbnail sizes not only on the horizontal, but also on the vertical axis. It achieves this by grouping the images into 2 to 4-element groups. It creates responsive layout, so the cells wrap into two lines on small sreens, provided at least 4 columns were set. (Note, as this layout constrains the images into pre-defined boxes, more cropping might occur.)

Related setting: Settings / Story / Design / Images / Thumbnail layout

4. More hero layout options

So far all styles had a 80% high hero, which can be monstrous for some. Even though you could shrink it down to 50%, most users didn’t bother with finding the related setting. Now every style comes with a different hero height, and you can size it down to even 30% of the screen height. Another change, that you now can completely remove the background image – a.k.a the theme image – so you can get a very clean and simple header if you’re after that. On top of this, the control bar can be moved above the hero, resulting in a more conventional web page layout. And if you have only a few folders or custom pages (e.g. About) you can have the top menu expanded on larger screens – like on this screenshot – which falls back to a hamburger menu on smaller screens.

Related setting: Settings / Story / Functions / Navigation / Expand on large screens

5. Auto-playing videos

A story can be made more exciting with videos. Even more if the videos automatically start when they get into focus. In the new version, the video closest to the center of the screen can be set to auto-start as you scroll. (Please note, as browsers since a few years block auto-start videos with sound, the first video might start muted. Once the visitor has allowed the sound, the further videos will start with sound.)

Related setting: Settings / Story / Design / Images / Autoplay video in view

Download Story skin →

No more character encoding problems

With jAlbum 29.3, we've added a setting that puts an end to character encoding problems. If you've ever had difficulties displaying galleries with file names containing so called "foreign" characters like "é, è, ü, Á and å", just tick this checkbox under Settings->Advanced->Naming:


Just tick it and jAlbum will use the "base characters" instead for generated file names, i.e. "e, u, A and a" respectively. If no title has been explicitly set for an object, jAlbum will use the original name without file extension as title.

Character encoding problems can have multiple causes, but it basically boils down to computer software using different techniques to represent foreign characters. In this help text, we explain how to resolve these issues.


jAlbum's own hosting naturally handles all possible characters. If you're using another hosting and face problems with foreign characters, this new setting will put an end to them.

jAlbum welcomes M1


With the introduction of jAlbum 29 we now offer a version that runs natively on Apple's M-series chips. This boosts performance significantly. Earlier versions of jAlbum have being relying on Apple's "Rosetta 2" emulation to convert Intel code to the ARM64 / AArch64 code that Apple's M-series chips uses. If it wasn't for the impressive performance of this chipset, the emulation would cause usability to suffer. Instead even an entry level M1 MacBook Air has been performing better than a 2015 MacBook Pro, but why stop there? Now with the introduction of direct M1 support we're boosting both startup performance and overall performance by a factor of 3:


 On an entry level M1 MacBook Air this corresponds to a startup time of less than 2 seconds!

 The same goes for image processing time:


We're mightily impressed how Apple has been able to combine such performance increase with lower energy consumption. I predict a great future for the ARM architecture, not only among small embedded devices and Linux servers, but also on desktop and laptop computers.

Our M1 version of jAlbum currently has one drawback: We haven't ported the native code RAW support yet. If this support is critical, then I suggest installing jAlbum 29 in parallel with v28.1 until RAW support is implemented.

I've never been a fan of Intel to be honest. In the '80s I was proud that my Amiga computer featured a full blown 32 bit Motorola 68000 series CPU. It was a decade ahead of Intel from an architectural stand point. I even had an "Intel outside" sticker on that computer. I'm eager to put that sticker back on my next laptop :-)


See jAlbum installers for various platforms




jAlbum 29. To the future and beyond

Tons of improvements rather than tons of new features. That could summarize jAlbum 29. We now also support Apple's new M-series computers, boosting performance 3x compared to the Intel based jAlbum version


With jAlbum 29, we've taken a leap from Java 14 to 19. That's 5 generations of major Java releases, including tons of fixes for various platforms and new functionality. We've also updated several 3:rd party code libraries providing faster and more robust image processing, native code interaction, better encryption and updates to the three scripting languages jAlbum supports (BeanShell, Groovy and JavaScript). These changes are like replacing the engine your car runs on with a brand new one, future proofing jAlbum for the coming years. The Mac version for instance, is now running on Apple's new "Metal" graphics library which promises better performance and lower energy consumption, but most important: jAlbum will continue to run on future Mac OSes.

Let's look into the improvements from three perspectives: performance, robustness and usability:


The updated image processing libraries are delivering significant performance enhancements to both image reading and writing, ranging from 1,25x to 5,6x the previous version (v28.1). The benchmarks here are gathered by performing multiple "Force rebuild" and "Make album" operations on v29 and v28.1. We've then compared the best performing operation on each version:



The updates to jAlbum, Java, encryption libraries and image processing libraries have improved robustness in many regards:

  • Improved HEIC image reading. Now handles certain iPhone 13 HEIC images as well
  • Improved TIFF image reading.
  • Improved PSD image reading
  • Improved stability on some Linux dialects
  • Scripting languages have been updated with several bug fixes
  • Now supporting more sftp encryption algorithms, now connecting with GoDaddy for instance
  • Better ability to recover projects from albums


 Perhaps not so noticeable at first glance, but various aspects of jAlbum's user interface and behavior have undergone improvements:

  • Windows users can now use "Show in file system" to have the selected image show up selected in the file system (Previously, only the parent window was opened)
  • Easier to set up monitored projects (projects that gets updated and uploaded once changes are made)
  • Monitoring is now paused for the currently open project (to avoid spurious updates while working on current project)
  • The System console now has more clever scrolling of output panel. It also now has the ability to execute statements in either panel
  • MultiMaker can now force rebuild projects. (Use ALT key)
  • MultiMaker now keeps green color on made projects until window is closed and reopened
As always, you can find the complete list of improvements in our release notes.
As always, jAlbum 29 is a free update to anyone who is on a current support & update plan, including anyone with a current Premium or Power account.
If your license isn't covering this version (check with "About jAlbum" menu), then we provide an updater's discount (usually 30% off). Just sign in and head to our purchase page.



How to deal with Google Fonts "data breach"?

Updated 2 maanden geleden

Update: Since 09/2022 all the bundled skin can download Google fonts and use locally, which does not fall under the scope the GDPR law. Just turn on Settings / skinName / Advanced / Copy Google Fonts to the album.

Recently we've heard from German users they were threatened by law firms because of the Google Fonts used on their sites.

Allegedly those firms collect those sites that use Google Fonts by bots. This way they are able to find even small sites visited by only a handful of people (perhaps relatives only), not posing any risk to their visitors' privacy. At first, I thought these firms were some kind of mafia, masquerading themselves as legal businesses, but they turned out to be real law firms. I believe if they were "bona fide" actors, they had not threatened website owners with a lawsuit right away - perhaps they could have called their attention to the problem first.

In January 2022 a German Court fined a website €100 for leaking their visitor's IP addresses via Google Fonts without their consent. Here's an article on the matter. So far nobody has paid attention to IP addresses, which normally tell a website where to send the requested content back. This is how the internet has worked in the past 30 years. These IP addresses for most home users are dynamic, i.e. they change day by day, and it's only the internet service provider can tell who had that particular IP address at a given time. Those who were afraid their IPs were revealed were already using anonymizers – I believe –, like VPNs or secure browsers (Tor).

Now, this court has decided it's the website that's responsible for hiding the user's IP from a service. Even though the website itself doesn't even know if the user has an IP address at all. It is the browser that sends it to Google Fonts, which is by the way Google Chrome for the majority, and we use Google Search, Google Drive, Android, and hundreds of services a day that reveal our IPs to Google. As the saying goes: "Google knows you better than you know yourself". You can't stop Google spying on you with a consent dialog.

Can you imagine how many dialogs you should "OK" if the dream of the inventors of GDPR law comes true? Thousands a day. Site visitors already take these popups as a pure annoyance, and click them away without a thought. What do they expect when a visitor is presented with the choice of revealing their IP or not, will they not visit a site because of this? Most people have no idea what an IP is, anyway. How do we expect them to make an educated decision?

Wouldn't it be a better approach if we have such preferences managed by the browser? It's easier to ask once if a user trusts Google Fonts than on every website.

It's a lawyer's world. I remember I had a car to which I had to make a contract every time I got in, promising that I will not be distracted by the entertainment system. I had to do this during driving most of the time. What if I sued the lawmakers for distracting me from driving? ;-)

In the case of heavy-weight data-harvesting services like Google Analytics or Facebook, it's easy to ask the visitor, and avoid loading them if they refuse it. However, with Google Fonts or jQuery "the damage is already done" when the consent dialog pops up, so there's no way of handling it nicely. You either refrain completely from using those services or you "violate the law".


What can you do to avoid "lawyers"?

First off, turn on "Avoid using Content Delivery Networks" under Settings / SkinName / Advanced panel, provided the skin offers this option. A Content Delivery Network is a third-party service that makes it quicker to load some external libraries. Even though the current wave of blackmails does not mention this, it might be their next target, I'm afraid.

Then choose a font that is not from Google, in Settings / SkinName / Site / Typography / Font family. Anything above (including) "Verdana" will do. Choose "[Same as base font]" as the Headline font.

Once ready with the settings, hit "Make album" and "Upload".

Needless to say, this affects only sites in the EU. And it seems, besides Germany nowhere has taken this so seriously.

We are currently working on a solution that loads those fonts from Google during the upload process to the target site, therefore no visitor IPs will be disclosed to Google.

Have a nice day,