From 6ff4ace20291427d827e31812b663eaa78101d31 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Kuba=20Grzechoci=C5=84ski?= <48084350+Skwiwel@users.noreply.github.com> Date: Sun, 18 Sep 2022 12:18:24 +0200 Subject: [PATCH] Clarify Bit-Packing doc example positioning When reading through the documentation I stumbled upon the Hybrid Bit-Packing section. The section is currently above the deprecated Bit-Packing encoding section, but refers to the example in the latter in a way that presumes the reader has already read it, which left me sightly confused. Here's an attempt to better point the reader to the other example so that he can easier compare both methods. --- content/en/docs/File Format/Data Pages/encodings.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/content/en/docs/File Format/Data Pages/encodings.md b/content/en/docs/File Format/Data Pages/encodings.md index b224336b..d140464b 100644 --- a/content/en/docs/File Format/Data Pages/encodings.md +++ b/content/en/docs/File Format/Data Pages/encodings.md @@ -68,7 +68,8 @@ repeated-value := value that is repeated, using a fixed-width of round-up-to-nex 1. The bit-packing here is done in a different order than the one in the [deprecated bit-packing](#BITPACKED) encoding. The values are packed from the least significant bit of each byte to the most significant bit, though the order of the bits in each value remains in the usual order of most significant to least - significant. For example, to pack the same values as the example in the deprecated encoding above: + significant. An example of the encoding is presented below. For comparison, the same case is shown + in the example of the deprecated bit-packing encoding in the next section. The numbers 1 through 7 using bit width 3: ```