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, with particular design philosophies that make use of modern C++ and established design patterns to create an engine that is easy to understand and extend. Note, however, that the engine is not designed to be especially robust, or even useful.

USAGE: sherpa_41 [options]

OPTIONS:
        --html                  HTML file to parse (=assets/rainbowBox.html)
        --css                   CSS file to parse (=assets/rainboxBox.css)
        -w, --width             Browser width (=800)
        -h, --height            Browser height (=600)
        -o, --out               Output file (=output.png)
        --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++. Both come pre-installed with most Linux distros, and are easy to install on MacOS and Windows.

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

For hacking on sherpa, please see the development notes below.

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

• Please try to break the application, and submit an issue or pull request when you do. I promise you can break it. Pretty easily. Okay, maybe very easily.

• There is no networking (yet!). I.e. so far, you can only show websites for which you have the HTML/CSS source.

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 and have at least 80% coverage.

The sherpa_41 repository includes a pre-commit hook to insure the codebase is formatted according to the .clang-format spec provided. To format the code, use clang-format -i include/**/*.hpp src/**/*.cpp tests/**/*.{hpp,cpp}.

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 or efficiency (done properly, these will usually lend toward each other anyway). Additionally, sherpa strives to adhere to modern, idiomatic C++, and effort should be taken to use this standard as much as possible.

2. Memory and type safety - sherpa_41's memory philosophy is Rust's in a C++ wrapper. This means RAII, dynamic allocation with unique_ptrs, and move semantics are taken large advantage of. 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. The most substantial bottlenecks for the engine are the renderers, which can often make millions of iterations, and the image/file processors (from Magick++). All stages of engine pipeline should be performant, and inefficiencies should not be introduced where they can be easily avoided. The biggest things here are to pass-by-reference or move all but primitively cheap values and to minimize object transmutation.

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