Simple browser engine.
sherpa_41
-rendered webpagessherpa_41
:mountain:sherpa_41
is a toy browser engine, based somewhat on
Limpet's Let's build a browser engine!
with architectures introduced in CS3251.
This app is meant to be explorative in nature, and is not designed to be especially robust, or even useful.
USAGE: sherpa_41 [options]
OPTIONS:
--html <file> HTML file to parse (Default: examples/sherpa-webpage.html)
--css <file> CSS file to parse (Default: examples/sherpa-webpage.css)
-W, --width <size> Browser width, in pixels (Default: 2880)
-H, --height <size> Browser height, in pixels (Default: 1620)
-o, --out <file> Output file (Default: output.png)
-h, --help Show this help screen
Almost any file type designed to show images can be used as the output file.
.png
, .pdf
, .jpg
are all great options, and you can even output to a
.html
file if you want.
An example of a custom invocation:
sherpa_41 --html index.html --css style.css -W 1800 -H 1200 -o myIndex.jpg
First, you will need CMake and Magick++.
Clone the repo and its dependencies, then make the project:
git clone --recursive https://github.com/ayazhafiz/sherpa_41.git
cd sherpa_41 && cmake .
make
./sherpa_41-test && ./sherpa_41
A summary of development notes is lower on this document.
The HTML parser currently supports elements, comments, and text nodes.
The CSS parser currently supports tag, class, id, and wildcard selectors, and has support for text, color (RGB/A, #HEX), and numerical unit declarations.
The Display module can currently issue commands to render rectangular block nodes.
Sherpa's Canvas renderer can currently generate basic webpages like the header.
There is no GUI renderer (yet?!). Until one is made, the front-end is really just an image. But a cool, nicely-rendered image, because sherpa has awesome renderers.
JavaScript is turned off by default, and can't be turned on. You may say JavaScript is unsupported. I say you're right.
If you patch this project, I'd love to see what you do. An issue or pull request is the easiest channel for communication.
When adding a new feature or module to sherpa_41
, please also add appropriate
GTests for it in tests/
. Generally,
the structure of the tests/
directory should mirror that of src/
.
Before submitting a PR, please take care that your changes pass on Travis.
The Travis build will fail if the codebase is not formatted to the
.clang-format
spec provided. To format the code, run something like
clang-format -i {src,tests}/**/*.(h|cpp)
.
sherpa_41
's DesignIn order of importance, Sherpa's main design goals are sound architecture, memory and type safety, and efficiency.
Sound architecture - because sherpa_41
is meant to be easy to explore
and extend, reusable components and solid design patterns are valued
overwhelmingly above succinctness and efficiency (of course, these aren't
mutually exclusive).
Memory and type safety - sherpa_41
's memory philosophy is Rust's in a
C++ wrapper. RAII, smart pointers, and move semantics are... the move. Here
may be where C++ idioms stray the most, with sherpa using static methods like
::from
to return unique pointers to polymorphic objects.
Efficiency - sherpa_41
has no excuse not to go fast. This mostly means
avoiding object transmutation. The performance of renderers could be improved
significantly.
idk, i got a sherpa jacket and thought the word sounded ambiguous enough to be a spectacular project name.