The HTML of the tables looks pretty much identical to what the web tester interface produces. Perhaps getting the keyboard colors it’s just a matter of a missing css file import? If I were to add an css import statement to the .php help file, would it just work or is there more to it? If adding the import line on my end would be a solution, what is the relative path and filename to use?
Alternatively, if a solution might be some time away, I would shift to using screenshots in the interim.
[Side note in the gff_amharic example of the link, the puncutation-2 layout appears as a broken table for the tablet layout. This layer doesn’t exist, so I’ll make this fix with my update.]
Thanks @darcy, following up on your recommendation from @Matthew_Lee keyboard I tried something similar which appears to work (causes no .kmn build issues). I want to avoid duplicating and renaming the css file if possible and now have this file structure:
Addressing the duplication of documentation content between help and welcome is a difficult issue. Some of the things we want to solve:
having a single source file for both website and embedded doc
path issues like this one
embedding styles (merging with help site styles where possible for continuity and readability)
testing help site content before publication
including and excluding HTML headers as required
using the Keyman Engine for Web documentation generation tags – can we make them available in Keyman as well (greatly simplifying the help file if so)
Coming up with a solid solution is on our radar. I wonder if using Markdown may be the answer with header metadata for styles, something like:
title: My Keyboard Help
In the midst of my pursuit of life, liberty, and something else, I came up with this keyboard which vitally switches the position of the A and the B and in doing so ...
It would compile down to html for the package build, and would mean a single source file for both site and package.
Markdown is lightweight, can embed html as needed
Styling is external to Markdown so should be able to inherit from welcome page structure and help.keyman.com more consistently
We use Markdown for metadata content already (README.md, etc)
Markdown is less accessible for some users than exporting to HTML from Word
More infrastructure for us to build and maintain in the package compiler and IDE
No immediate and automatic pathway from welcome.htm to welcome.md, although tools do exist to help with transform.
Tangentially related, I would like to show a different welcome.htm page in the keyman installer when the installation is on a mobile phone or tablet. The “welcome” info that I wrote for desktops is not so relevant for these other platforms, even misleading. Is there a special div class that can show/hide content based on the current platform?
As it is a rather large page, it may help to look for the <div> elements with the class="tab-content" attribute. There are two of them, and they’re the top-level elements for the two separate sections.
As long as only one of the two sections is visible at a time, the net effect should achieve what you want.