{"id":20296953,"url":"https://github.com/nbehrnd/bader_article","last_synced_at":"2026-03-01T04:34:21.965Z","repository":{"id":252250541,"uuid":"838529597","full_name":"nbehrnd/bader_article","owner":"nbehrnd","description":"«Putting Fortran's object-related features to practical use» a draft prepared by the late Reinhold Bader (1966-2024)","archived":false,"fork":false,"pushed_at":"2024-10-10T20:33:15.000Z","size":12642,"stargazers_count":3,"open_issues_count":0,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-06-13T09:09:16.816Z","etag":null,"topics":["fortran","fortran2003","modern-fortran","oop"],"latest_commit_sha":null,"homepage":"","language":"HTML","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nbehrnd.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-08-05T20:39:25.000Z","updated_at":"2024-10-10T20:33:20.000Z","dependencies_parsed_at":"2025-01-14T09:46:39.107Z","dependency_job_id":"4cdb8553-fee9-47e3-972d-a3132fdac7b1","html_url":"https://github.com/nbehrnd/bader_article","commit_stats":null,"previous_names":["nbehrnd/bader_article"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/nbehrnd/bader_article","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nbehrnd%2Fbader_article","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nbehrnd%2Fbader_article/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nbehrnd%2Fbader_article/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nbehrnd%2Fbader_article/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nbehrnd","download_url":"https://codeload.github.com/nbehrnd/bader_article/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nbehrnd%2Fbader_article/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29960253,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-01T01:47:18.291Z","status":"online","status_checked_at":"2026-03-01T02:00:07.437Z","response_time":124,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["fortran","fortran2003","modern-fortran","oop"],"created_at":"2024-11-14T15:42:18.675Z","updated_at":"2026-03-01T04:34:21.951Z","avatar_url":"https://github.com/nbehrnd.png","language":"HTML","funding_links":[],"categories":[],"sub_categories":[],"readme":"---\ntitle: readme.md\ndate: 2024-08-05 Mon\nedit: 2024-10-10 Thu\n---\n\n# purpose\n\nFollowing a call for help by M. B. Metcalf on\n[fortran-lang.org](https://fortran-lang.discourse.group/t/reinhold-bader-1966-2024/8233/5),\nthis project aims to preserve a draft prepared by the late Reinhold Bader\n(1966-2024) about aspects of object oriented programming in Fortran.\n\nIntended for eventual use in Wikipedia (see this page\n[here](https://en.wikipedia.org/wiki/User:RBaSc/draft_ftnoo))\nit is/was uncertain if Baders' work would remain accessible there, or not.  A\nreader primary interested in the topics of OOP and Fortran is suggested to\nconsult either file\n[`ex_pdflatex.pdf`](ex_pdflatex.pdf),\nor the primary source file of the draft,\nfile\n[`pandoc_md.md`](pandoc_md.md).\n\n## technical details\n\nThe initial format of the draft (mediawiki syntax) eventually was translated\nwith [pandoc](https://pandoc.org/) (version 3.1) into _Pandoc_ flavored markdown\nas a markup language easier to maintain and use.  Reasons for this move include\n\n- the provision of labeled fenced code blocks as a basis for eventual syntax\n  highlighting (a feature GitHub flavored markdown equally can provide)\n- support of cross-links to earlier sections of the same document (apparently\n  GitHub flavored markdown only supports links to external documents)\n\nThese outweigh drawbacks like the incorrect/unresolved display of internal\ncross-links by GitHub because the platform presumes file extension `.md` refers\nto a _GitHub_ flavored markdown file.  (Pandoc has flags to discern these\ndialects for file I/O.)\n\nThe two illustrations originally fetched (png, given the dimensions they were\nused, of low resolution) were redrawn with [inkscape](https://inkscape.org/)\n(inheritance diagram), or\n[draw.io desktop](https://github.com/jgraph/drawio-desktop/releases) (UML\ndiagram).  They were exported both into vector formats (.svg, .pdf) and bitmap\n(.png with at least 300 dpi given the dimensions of anticipated usage).  Beside\nan increase of readability in the pdf to compile, this provided an easier edit\nand correction at the source, if needed.\n\nWhile aiming for a pdf as eventual output (cf. _vide infra_), the (re)build of\nthe document was monitored by a conversion of the markdown file with Pandoc into\nhtml (default action) or a pdf intentionally without illustrations (with groff).\nLike other actions of this project likely to be used multiple times, a\n[Makefile](Makefile)\nwas used to manage these.\n\nPandoc offers multiple `--pdf-engines` for a _direct_ compilation of a pdf.  In\naddition, Pandoc can convert e.g., a markdown file into an other markup language\nwhich itself can be used to compile a pdf using a different engine of its\necosystem.  Thus, beside the preservation of Bader's draft, a second interest of\nthe project's owner was to compare a few possible workflows.  This may be\nattractive because markdown (used as the container format to edit the draft) is\na lighter markup language than LaTeX for instance to define emphases, or tables\nwhile the visual appearance of the eventual document can be influenced by Pandoc\nstyle templates.\n\n- The workflow via pdfLaTeX eventually uses an edited version of the\n  [eisvogel](https://github.com/Wandmalfarbe/pandoc-latex-template) template.\n  For greater portability of the project between two operating systems (Windows\n  and Linux Debian), the choice of the template's author for\n  [`sourcesanspro`](https://ctan.org/pkg/sourcesanspro) was substituted\n  by a set of font families arguably more frequently seen\n  ([`libertine`](https://ctan.org/pkg/libertine),\n  [`libertinust1math`](https://ctan.org/pkg/libertinust1math),\n  and\n  [`beramono`](https://ctan.org/pkg/bera)) to support the display of text,\n  mathematics, and source code (cf.\n  [LateX Font Catalogue](https://tug.org/FontCatalogue/mathfonts.html)).\n  On a pristine user account within the Windows operating system, this still\n  required a considerable amount of permanent memory to resolve the dependencies\n  (i.e., many usepackages, including their dependencies) before the pdf intended\n  was compiled smoothly.\n\n  Out of the three workflows tested, its result (see file\n  [`ex_pdflatex.pdf`](ex_pdflatex.pdf))\n  is the most recommended in terms of reliable coverage of the contents and\n  visual appearance of the pdf written.\n\n  Other `--pdf-engines` related to TeX (lualatex, xelatex, etc) Pandoc offers to\n  use were not tested.  At present, the project's owner can not access to them,\n  and does not (yet) have sufficient user experience using them.\n- To test the (intermediate) format of\n  [restructured text](https://en.wikipedia.org/wiki/ReStructuredText)\n  (.rst) was appealing because of its frequent use to document Python projects\n  ([Sphinx](https://en.wikipedia.org/wiki/Sphinx_(documentation_generator))).\n  Compared to this, [rst2pdf](https://rst2pdf.org/) which is a tool with lesser\n  footprint.  Here, mathematical equations are rendered with Python's\n  [`mathplotlib`](https://matplotlib.org/)\n  as bitmaps which eventually are embedded into the document.  The presence of\n  the later thus can facilitate the additional setup to use this approach.\n\n  Compared to the previous workflow with pdfLaTeX, the compilation yielded a\n  pdf about twice as large (1.5MB, see file\n  [`ex_rst.pdf`](ex_rst.pdf)).\n  In one case, while approaching the end of a page, this tool didn't relay the\n  illustration across the page break to the next page.  Instead, the picture was\n  squeezed into the remainder of the page.  So far, I did not identify a method\n  to assist rst2pdf to resolve this \"floating problem\".\n- Tools around (g)roff typically already are on board of a Linux distribution\n  (management of man pages, etc), or easily installed if missing.  Compared to\n  the workflow with either pdfLaTeX, or rst2pdf \u0026 mathplotlib, their footprint\n  for permanent and working memory usually is smaller, the pdf is compiled\n  faster.  In the present project, the Pandoc written intermediate .ms file\n  required a couple of adjustments ahead of the eventual compilation of the pdf\n  (cf. the corresponding section in the\n  [`Makefile`](Makefile)).\n  One of the mathematical characters (mapsto) was too special and had to be\n  constructed manually.  Perhaps the setup of of a non-default font to groff\n  (see e.g., Peter Schaffter's\n  [documentation](https://www.schaffter.ca/mom/momdoc/appendices.html#fonts))\n  would remove this hurdle.\n\n  It equally is noteworthy that groff's pre-processor `pic` requires the\n  illustrations either in the .eps format (preferred, embedded into the .ms file\n  as `PSPIC`), or .pdf format (acceptable as \"unsafe\" option, embedded into the\n  .ms file as `.PDFPIC`).  This wasn't problematic because the illustrations\n  were available as vector graphics; the update of the .ms file equally can be\n  provided with `sed` launched from the\n  [`Makefile`](Makefile).\n  (One could embed png into a pdf container with e.g., Imagemagick's\n  [convert](https://imagemagick.org/script/convert.php),\n  though on expense loosing advantages of an illustration provided in a vector\n  format.)  The result (see file\n  [`ex_groff.pdf`](ex_groff.pdf))\n  was the smallest of all three workflows tested.\n\n## summary\n\nThe table below compares the file sizes of the pdf generated by either one of\nthe three workflows tested (column \"original\") and eventually stored in the\nproject archive.\nOften, file sizes of pdf can be reduced further by an additional \"print to pdf\".\nAs an example, the file sizes of a run like `pdf_rewrite -r input.pdf` with\n[pdf_rewriter](https://github.com/nbehrnd/pdf_rewriter) to retain the colors of\nthe illustrations are compiled in column \"rewritten\".\nColumns \"good\" and \"bad\" are an opinionated selection of advantages /\ndisadvantages of either workflow.\n\n| workflow | original | rewritten | good | bad |\n| :--- | ----: | ----: | :-------- | :-------- |\n| pdfLaTeX | 794 kB | 415 kB | character set covers the needs, reliable management of illustrations (either png, or pdf) | large footprint to install |\n| rst2pdf  | 1.5 MB | 1.0 MB | relates to the Python ecosystem | slow processing, results large pdf |\n| groff | 680 kB | 190 kB | light footprint, fast processing | less symbol coverage than LaTeX, illustrations need to be in a pdf/eps container |\n\n## update summary\n\n- 2024-09-03 Tue: a comment by Brad Richardson regarding when interfaces are\n  considered as sufficiently different (section 18.3) is added.\n- 2024-10-10 Thu: The draft as initially secured here served to prepare a\n  booklet for the learning materials of fortran-lang.org.  This proved the\n  initial organization of the material in chapters, sections, and sub sections\n  by Bader was not fully respected during the \"rescue\".  This update now puts\n  the elements back into their intended hierarchy.  In addition to this, results\n  of adjusting the style for a submission to fortran-lang.org (e.g., 2 instead\n  of 3 spaces per level of indentation, lower case Fortran keywords anyway\n  subject of syntax highlighting) were amended to this repository.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnbehrnd%2Fbader_article","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnbehrnd%2Fbader_article","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnbehrnd%2Fbader_article/lists"}