Add the Style and About pages

Style describes the one layout the formatter produces: wrapping, lambdas, call chains, long strings, imports and comments, and three trade-offs. Every Java block on it was run through a build of the formatter and comes back unchanged, so the page shows output rather than intent. Two things came out differently from the old README the material came from: a chain is split only when everything before its last dot passes 80 columns, and before splitting the formatter first tries moving the whole chain to the next line; Javadoc and block comments are left as written, while line comments are wrapped. The trade-offs name the $NON-NLS$ markers that end up on another line, with the formatter's output as the example.

About says where the formatter is published, that the Maven Central artifacts and the GitHub release files come from the release workflow, as the 2.98.0.1 run shows, and how to check a download. The release key's fingerprint and the import command were checked against keys.openpgp.org, and the signature of the 2.98.0.1 checksum file verifies with it. Planned work is pointed at the issues, because the roadmap left the formatter's README.

Author: abashev

docs/about.md

@@ -0,0 +1,55 @@
+# About
+
+open-java-format is a Java formatter developed in the open. It began as a fork of
+palantir-java-format, which is itself a fork of google-java-format, and every artifact is now built
+and published from [its own repository](https://github.com/openjavaformat/open-java-format). Why the
+project exists is in the [manifesto](manifesto.md).
+
+## Where it is published
+
+| Where | What |
+| --- | --- |
+| [Maven Central](https://central.sonatype.com/namespace/dev.openjavaformat) | `dev.openjavaformat:open-java-format`, with `-spi`, `-native` and `-jdk-bootstrap` |
+| [Gradle Plugin Portal](https://plugins.gradle.org/plugin/dev.openjavaformat.java-format) | `dev.openjavaformat.java-format` |
+| [JetBrains Marketplace](https://plugins.jetbrains.com/plugin/34359-open-java-format) | the IntelliJ IDEA plugin |
+| [GitHub Releases](https://github.com/openjavaformat/open-java-format/releases/latest) | native binaries, the runnable jar, the IntelliJ IDEA and Eclipse plugins |
+
+The Maven Central artifacts and the files of a GitHub release are built by the
+[release workflow](https://github.com/openjavaformat/open-java-format/blob/main/.github/workflows/release.yml)
+from the tag of the version.
+
+## Verify a download
+
+Each file of a GitHub release has a `.asc` signature next to it, and so does each artifact on Maven
+Central. They are made with the project's release key:
+
+``` text
+13A6 BDF2 DAA9 8D3D 573B  33EA 1004 81FD AEE9 4DE9
+```
+
+The key is published on [keys.openpgp.org](https://keys.openpgp.org). Import it once, then check the
+checksum file of a release, and the checksum file against your download as shown on the
+[Command line](get-started/command-line.md#verify-the-download) page.
+
+``` sh
+curl -sSL https://keys.openpgp.org/vks/v1/by-fingerprint/13A6BDF2DAA98D3D573B33EA100481FDAEE94DE9 | gpg --import
+gpg --verify checksums_sha256.txt.asc checksums_sha256.txt
+```
+
+A good signature ends with the fingerprint above. gpg also warns that the key is not certified with a
+trusted signature, because nobody in your keyring has signed it: compare the fingerprint instead.
+
+## Licence
+
+open-java-format is distributed under the
+[Apache License 2.0](https://github.com/openjavaformat/open-java-format/blob/main/LICENSE), like
+palantir-java-format and google-java-format, and it keeps the copyright notices of both. Neither
+Palantir Technologies Inc. nor Google LLC endorses, sponsors or is affiliated with it.
+
+## Take part
+
+- Report a bug or propose a change in the
+  [issues](https://github.com/openjavaformat/open-java-format/issues), where planned work is tracked
+  too.
+- Every page of this site has an **Edit this page** button, which opens a pull request against
+  [its sources](https://github.com/openjavaformat/docs).

docs/style.md

@@ -0,0 +1,162 @@
+# Style
+
+open-java-format has one style and no settings. It is the style of palantir-java-format 2.x, which
+grew out of google-java-format: lines of up to 120 characters, 4 spaces for each level of
+indentation, and 8 more for a line that continues a statement. Every example on this page is the
+formatter's own output.
+
+## Wrapping
+
+When a declaration does not fit on one line, its parameters move to a continuation line together.
+
+``` java
+class Params {
+    public static ResolvedConfiguration resolveConfigurationForProject(
+            Project project, String configurationName, boolean includeTransitiveDependencies) {
+        return resolve(project, configurationName, includeTransitiveDependencies);
+    }
+}
+```
+
+## Lambdas
+
+A lambda starts on the line of the call it is passed to, and its body is indented by one level from
+that line, however deeply the call is nested.
+
+``` java
+class Tasks {
+    void register(Project project) {
+        project.getTasks().register("formatDiff", FormatDiffTask.class, task -> {
+            task.setGroup("formatting");
+            task.setDescription("Formats the lines you changed");
+        });
+        executor.submit(() -> {
+            runChecks();
+        });
+    }
+}
+```
+
+A short lambda stays on the line of its call, also inside a chain.
+
+``` java
+class Lambda {
+    private static GradleException notFound(String group, String name, Configuration configuration) {
+        String actual = configuration.getIncoming().getResolutionResult().getAllComponents().stream()
+                .map(ResolvedComponentResult::getModuleVersion)
+                .map(mvi -> String.format("\t- %s:%s:%s", mvi.getGroup(), mvi.getName(), mvi.getVersion()))
+                .collect(Collectors.joining("\n"));
+        return new GradleException(actual);
+    }
+}
+```
+
+The [home page](index.md#what-the-output-looks-like) shows the same kind of code next to the output
+of google-java-format.
+
+## Call chains
+
+A chain of calls stays on one line only if everything before its last dot fits in 80 columns, even
+when the whole statement would fit in 120. Otherwise each call goes on a line of its own, which keeps
+builders and streams easy to read and to diff.
+
+``` java
+class Chains {
+    void f() {
+        var request = HttpRequest.newBuilder()
+                .uri(uri)
+                .header("Accept", "application/json")
+                .timeout(timeout)
+                .build();
+        var user = User.builder().name(name).email(email).build();
+    }
+}
+```
+
+On one line the first statement would be 118 characters long, with its last dot in column 110. The
+last dot of the second one is in column 58.
+
+When moving the whole chain onto the next line brings its last dot within the limit, the formatter
+does that instead of splitting it.
+
+``` java
+class Chains {
+    void f() {
+        var foo =
+                SomeType.builder().thing1(thing1).thing2(thing2).thing3(thing3).build();
+    }
+}
+```
+
+## Long strings
+
+A string literal that runs past column 120 is split between words, and the rest continues after a
+`+` on the next line. On the command line, `--skip-reflowing-long-strings` turns this off.
+
+``` java
+class Strings {
+    String message =
+            "The formatter reflows a string literal that runs past the column limit, and it keeps the words intact"
+                    + " while doing so.";
+}
+```
+
+## Imports
+
+Static imports come first, then a blank line and the other imports, each group in ASCII order.
+Imports the file does not use are removed: the input of this example also imported `java.util.Map`
+and `java.util.Set`. On the command line, `--skip-sorting-imports` and
+`--skip-removing-unused-imports` turn these off.
+
+``` java
+package com.example;
+
+import static java.util.Objects.requireNonNull;
+
+import com.google.common.collect.ImmutableList;
+import java.util.List;
+
+class Imports {
+    List<String> names = ImmutableList.of(requireNonNull("a"));
+}
+```
+
+## Comments
+
+A `//` comment that runs past column 120 is wrapped onto a new `//` line. Javadoc and `/* */`
+comments are kept exactly as written, however long their lines are.
+
+``` java
+class Comments {
+    // A line comment that runs past the limit of one hundred and twenty characters is wrapped, and the rest continues
+    // on a line of its own.
+    int x;
+
+    /** Javadoc is kept exactly as it is written, however long its lines are, because the formatter does not reflow it. */
+    int y;
+}
+```
+
+## Trade-offs
+
+- **The layout follows the syntax.** The formatter does not know which grouping of arguments reads
+  best. When a layout comes out awkward, a local variable or a small method usually fixes it, and the
+  fix holds on every later run.
+- **A `$NON-NLS$` marker can end up on another line.** Eclipse expects the marker on the line of the
+  string it marks. When the formatter wraps such a statement, the string moves to a line of its own
+  and the marker stays at the end of the statement:
+
+    ``` java
+    class Messages {
+        void f() {
+            label.setText(Messages.format(
+                    "The configuration of the project could not be read",
+                    projectName,
+                    configurationFileName)); // $NON-NLS-1$
+        }
+    }
+    ```
+
+- **Layout fixes of our own wait for 3.x.** For the whole 2.x line the output is byte-for-byte the
+  same as the palantir-java-format release with the same version number. The
+  [manifesto](manifesto.md) explains why output stability comes first.

zensical.toml

@@ -26,12 +26,14 @@ nav = [
     { "GitHub Action and pre-commit" = "get-started/github-actions.md" },
   ] },
   { "AI agents" = "ai-agents.md" },
+  { "Style" = "style.md" },
   { "Library rules" = [
     "library-rules/index.md",
     { "Flogger" = "library-rules/flogger.md" },
   ] },
   { "Migrate" = "migrate.md" },
   { "Manifesto" = "manifesto.md" },
+  { "About" = "about.md" },
 ]
 
 # extra_css = ["stylesheets/extra.css"]