Harmonization of the internet presence
With the move of the
abeamer-release git pages to the abeamer.com domain, this become the home of 4 visual components: website, blog, documentation and gallery, but all of these components were built using different tools, which lead to having 4 components with different visual appearances, and not the feeling of being integrated with the domain visual look.
The website was built with a mix of bootstrap, scss, gulp and liquid templates, the blog was built with jekyllrb, the documentation was built with mkdocs and finally the gallery was built with a mix of marked, and some typescript code.
Most of work since the last ABeamer release was done on the harmonization of these 4 components, in order for the user feel that each component has part of a whole. This work was done outside the scope of the abeamer git repo. All the code regarding visual customizations was removed from this repo, and ported to the website scripts which aren’t available for public domain.
Although there is still some work to be done in this area, and a few bugs to fix, right now the user can already navigate from component to component without the feeling that he is in a different domain.
Reducing the dependence of npm
In the last version of ABeamer 1.2, I tried multiple times to publish using email@example.com, but it was constantly reporting an error during the publishing phase, and not allowing to retry the version was original planned, hence the previous published version is 1.2.3 and not the 1.2.0 as intended.
It’s not the first time that npm creates problems and according to the experience of some users, some of them would prefer to have a version that doesn’t depends on npm.
To reduce the dependence of npm, I have included the abeamer.sh and abeamer.cmd for those users who wish to download directly from downloads page.
Node includes npm as the official package manager, and puppeteer, scss and typescript are installed as npm packages, with the last two being optional, but probably these requirements might be installed without npm. I haven’t done much research on this field yet.
Chrome Server Render Font Bug
gallery/animate-transitions had a problem when it generated frames of using incorrect font which I have been trying for the a long time to understand why.
At the moment, I’m doing the tests on a linux machine running firstname.lastname@example.org and email@example.com, and with this configuration, Chrome while rendering on the client, I could see the text being rendered with
Open Sans but when it rendered on the server it used a
I would imagine, it could be due the Chrome font fallback policy, but in this case it wasn’t even falling back to
sans-serif, it simply fallback to a
serif font. Today, I did a lot of testing by trying to change all sort of parameters to this equation, to find the culprit of this situation, and finally I found the problem was on defining the font on the
class and not on the id.
So if I have instead the following code:
It renders properly on a web browser and also when it generates the PNG file sequence as well. Defining the font in the class instead of the id, is the preferred method since ABeamer will probably evolve into a multi-story engine for client rendering. At the moment, there is no plans for multi-story support in the server rendering, but multi-story in the client could open doors to new usages.
Another option could be define the
font-family and other font parameters directly on the body, but this could limit the possibilities of adding toolbars and widgets to the webpage using for client rendering.
At the moment, when
story.render is executed, ABeamer adds a
clip-path to both the story and the body, this was done to prevent elements that went outside the story from being visible.
This method solves several problems that appear during the creation of the gallery, but now it prevents from creating multi-stories and add other elements outside the story, such as toolbars and widgets, that aren’t supposed to be server rendered.
I’m doing research on the best strategy to solve the original problem without limiting the capacities of ABeamer.