_{sherpa_41-rendered webpages}

sherpa_41 ⛰️

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

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

Building

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.

Features

• 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.

Notes

• 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.

Development Notes

Adding features

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).

A Brief Overview of sherpa_41's Design

In order of importance, Sherpa's main design goals are sound architecture, memory and type safety, and efficiency.

1. 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).

2. 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.

3. Efficiency - sherpa_41 has no excuse not to go fast. This mostly means avoiding object transmutation. The performance of renderers could be improved significantly.

etymology

idk, i got a sherpa jacket and thought the word sounded ambiguous enough to be a spectacular project name.