Plain-Text Chapters (TXT)
A plain-text multi-chapter SAMPLE extract — for ebook converters that accept .txt sources.
SAMPLE CHAPTERS
Chapter One
A short plain-text ebook extract for importer tests.
Chapter Two
Second chapter keeps structure obvious for splitters.
Specifications
- Chapters
- 2
- Encoding
- UTF-8
Testing contract
Expected to pass- Scenario
- Exercise Plain-Text Chapters (TXT) in its plain workflow. A plain-text multi-chapter SAMPLE extract — for ebook converters that accept .txt sources.
- Expected result
- 7 text lines, decoded as UTF-8; first nonempty line is 'SAMPLE CHAPTERS'. Declared feature checks: chapters=2.
What is a .txt file?
TXT is a plain-text file containing unformatted character data with no styling or structure beyond line breaks. Its interpretation depends on character encoding, most commonly UTF-8, and on line-ending convention. It is the most universal and portable text container.
How to use this file
Use an example TXT to test encoding detection, line-ending (LF versus CRLF) handling, and any tool that reads or streams raw text input.
How to use this file for testing
“Plain-Text Chapters (TXT)” is a deterministic Novus Examples fixture for Encoding detection, Editor testing. UTF-8, UTF-8-BOM, UTF-16, and Latin-1 files with documented encodings and line endings for testing charset detection.
Documented properties for this file: UTF-8. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such, expect parsers to fail loudly rather than silently accept them.
E-book fixtures are structured archives documented down to their spine and manifest. Test readers and converters, and where a valid↔intentionally-invalid pair exists, assert graceful handling of the malformed container.
Related files
- yamlDocker Compose Anchors and x- Extension FieldsCompose with three x- extension fields carrying YAML anchors that are merged into services. The trap is ordering: a tool that strips x- keys before parsing the YAML destroys the anchors and the file stops resolving.
- patchGit Patch - CRLF Line Endings ThroughoutThe whole patch file uses CRLF terminators, as it would after a round trip through a Windows editor or a mail client. `git am` needs `--keep-cr` to be told the CRs belong to the patch rather than to the content, and the `-- ` signature line now ends with space-CR-LF.
- patchGit Patch - LF Line Endings ThroughoutThe LF half of the patch twin pair, identical in text content to the CRLF fixture. Diff the two downloads to get a change that is invisible in every renderer and fatal to a byte comparison.
- ymlGitHub Actions on: Key YAML Boolean TrapThe workflow file that exposes the YAML 1.1 boolean resolver: a bare `on` key becomes True in PyYAML, SnakeYAML and Psych, so a round-trip through those loaders loses the trigger block. The env values repeat the trap with NO, yes and off alongside a quoted control.
- ymlGitLab CI !reference Custom YAML TagGitLab's `!reference` custom YAML tag used three ways: inside a script list, as a whole after_script value, and as a whole rules value. A stock YAML 1.2 loader has no constructor for it and raises; GitLab's loader resolves each key path.
- ymlGitLab CI Anchors and ExtendsThe two GitLab inheritance mechanisms in one file: YAML anchors with merge keys, which the loader resolves before GitLab sees the document, and `extends`, which GitLab resolves afterwards with a deep merge. Hidden .job keys carry both.
Generated by generation/ebooks_wave_c.py. Free for any use, no attribution required, license.