Andy Kopra
6e7596ab2e
A named group of optional parameters, declared once and used by several
klammers, so a writer learns one vocabulary instead of a spelling per
klammer. The "o" target is a pseudo-target beside "k": "k" declares a
klammer's interface and documents it, "o" declares an option interface and
documents it, and neither produces output for any target.
@@caption_args.o :caption :number.bool true :caption_side.side
: Arguments that define a caption for a block element @@
@@code.k :filename @hpos_args :hpos left @ @caption_args :caption_side top @
| text.literal : A source file displayed verbatim @@
A set is used only in the parameter list of a ".k" declaration -- the one
place a klammer's interface is declared once for all of its targets -- and
is resolved as that list is read. Names and types come from the set; a
default may be overridden where it is used. A klammer application in a
parameter list is now a definition-time error.
The SKS gains the sets caption_args and hpos_args (:hpos and :offset), and
@table, @image, @image_grid, @reference and @show gain .k declarations. A
distance is no longer written as a position: :hpos 4em is rejected, and the
same layout is :hpos left :offset 4em. Code listings are numbered by
default, like tables and figures.
New engine sources mac/option_set{,_registry}.{h,cpp}; tst/ ships two more
suites, option_set_test.sh and signature_test.sh (twelve in all).
(from dev 34e536cb0329)
91 lines
3.2 KiB
CSS
91 lines
3.2 KiB
CSS
.code {
|
|
font-family: var(--monospace);
|
|
}
|
|
|
|
/* A whole listing, inside its :hpos position container. Full width by
|
|
default so an annotated listing's comment column has a remainder to take
|
|
(.code_comment is flex: 1); an UNANNOTATED listing is shrink-to-fit
|
|
instead, which is what lets :hpos center or right-align it -- a
|
|
full-width child cannot be moved within its container. The LaTeX
|
|
counterpart is Code.tex_place. */
|
|
.code_listing {
|
|
}
|
|
|
|
.code_listing_box {
|
|
width: fit-content;
|
|
}
|
|
|
|
/* An annotated code listing (sks/code/code_block.py). The same model as
|
|
the LaTeX side in sty/code.sty: each BLOCK is a run of code lines with
|
|
an optional comment beside it, the shaded box is as wide as that block's
|
|
longest line, and comments sit a fixed distance from their own block
|
|
without aligning with each other.
|
|
|
|
align-items: center is the counterpart of LaTeX's \parbox[c] pair. No
|
|
vertical margin or padding anywhere in the stack: consecutive blocks
|
|
must abut exactly, so that adjacent shaded blocks read as one region and
|
|
the line rhythm is the same whether a line is shaded or not. That is
|
|
what \strut and \offinterlineskip buy on the LaTeX side; here it is just
|
|
the absence of vertical space. */
|
|
.code_block {
|
|
display: flex;
|
|
align-items: center;
|
|
margin: 0 0 0 1rem;
|
|
padding: 0;
|
|
}
|
|
|
|
.code_caption {
|
|
margin-left: 1rem;
|
|
font-style: italic;
|
|
}
|
|
|
|
/* white-space: pre keeps the code's own spacing, and the shrink-to-fit
|
|
width of an inline-block IS the block's longest line — so the shading is
|
|
one solid rectangle with no per-line work and nothing measured. Padding
|
|
is horizontal only; see the note on .code_block. */
|
|
.code_text {
|
|
display: inline-block;
|
|
white-space: pre;
|
|
font-family: var(--monospace);
|
|
line-height: 1.4;
|
|
/* No horizontal padding: the box's left edge sits ON the code column,
|
|
where the line's own indentation begins, rather than out to the left
|
|
of it. LaTeX counterpart: \klcodepad 0pt. */
|
|
padding: 0;
|
|
}
|
|
|
|
/* The comment takes what the block leaves of the containing width — the
|
|
browser's counterpart of \dimexpr\linewidth-\klcodewidth-\klcodegap.
|
|
min-width is the counterpart of \klcodemin: below it the comment would
|
|
be too narrow to set prose in. */
|
|
.code_comment {
|
|
flex: 1;
|
|
padding-left: .75rem;
|
|
font-family: var(--sans-serif);
|
|
font-style: italic;
|
|
font-size: .8rem;
|
|
min-width: 100px;
|
|
line-height: 1.25;
|
|
}
|
|
|
|
/* An annotated block: background only, no border. A border would need a
|
|
matching one on the unshaded blocks to keep the code aligned, and the
|
|
design settled on shading alone. */
|
|
.code_border {
|
|
background-color: rgb(100%,100%,60%);
|
|
/* Clear space above and below a boxed block, so two boxed blocks with
|
|
no unboxed lines between them read as two boxes rather than one.
|
|
On the block, never on the line: the lines within a block must still
|
|
abut, or the shading stops being a solid rectangle. The LaTeX
|
|
counterpart is \klboxgap in sty/code.sty. */
|
|
margin: 2px 0;
|
|
/* The box's own vertical margin: space inside the shading, above the
|
|
first line and below the last. LaTeX counterpart: \klboxpad. */
|
|
padding-top: 2px;
|
|
padding-bottom: 2px;
|
|
}
|
|
|
|
.code_no_border {
|
|
}
|
|
|