It's rendered incorrectly. To fix, it probably will require some regex replacement,
but it may the the case that the "'" character to be used in a special meaning on some languages.
Need to check that before trying to solve this.

This does not happen in pdfLateX, only in XeLateX

Moved from ancap-ch/from-en#1636

Refactor functions and procedures, so they are easier to maintain and to tweak/refactor/expand later.

• favor modularized design
• favor toml over yml
• favor html server over native gui
• have other engines over "xetex only"
  • related: ancap-ch/from-en#1627
  • related: ancap-ch/from-en#1630
• favor "no translation server" over having crowdin/utopian workflow
  • related: #7

books

• Economics and Ethics of Private Property - the remaining of Part II [by Hoppe]
• The Law (~100 pages) [by Bastiat]
• Ethics of Liberty (~350 pages) [by Rothbard]
• Democracy: The God That Failed (~380 pages) [by Hoppe]
• Defending the undefendable (~220 pages) [by Walter Block]
• Economic Science and the Austrian Method (~80 pages) [by Hoppe]
• Against Intelectual Property (~60 pages) [by Kinsella]
• Human Action (~1000 pages) [Ludwig von Mises]
• Man, Economy and the State (~1500 pages) [by Rothbard]
• (more..)

essays

• Economic Depressions: Their Cause and Cure (~20 pages) [by Rothbard]
• (more..)

Moved from ancap-ch/from-en#1218

In markdown, if a footnote has a consecutive paragraph, it starts the line with " " (four spaces). This is a formatting information that is easy to lose when translating.

So, for future texts, "~~~~" should be used instead, so that this information is much less-likely to get lost. Then I'll just replace it back to spaces before rendering the files.

Also, it is very desired to have a script to check, on original files, if there is any case of those consecutives paragraphs (any case of " " on the beginning of the line). If this is the case, the footnote and this cases count should be recorded, and then later, compared to the translated text. If the translation's count is less, it should be notified that there is formatting information that was lost.

Then I'll just go and fix it on Github.

Footnote consecutive paragraph now starts with ...., since ~~~~ would already have a strike-thru meaning in some markdown visualizers.

Nevermind, 4 dots are ambiguous since it's unknown if the author omitted some text.
It will be :::: instead, since this is not used for anything and don't distract that much

pdf render updated: bc01ca4

there are new options, such as "check footer". It will count multi-lined footers from original files and will compare with the selected translations.

ps. the original file footer was incorrect, it appears that crowdin erased that explicit formatting information, although it was in the end of the file.

So the count differences are shown:

It informs the markdown index (should also print it's name), and highlights which footnote is wrong (should also show it's explicit number).

Before closing, it needs to also verify if the total number of footnotes, not only their line count, is the same.
Must error if it's not.

Moved from ancap-ch/from-en#1198

Even if it supports two lines of chapter, the third line messes everything.
One possible workaround is to, somehow, erase everything after the colon ":" of the chapter, if it's detected that it's too big.

Moved from ancap-ch/from-en#1635

Moved from ancap-ch/from-en#1427

There is a resourceful infographics scheme on overleaft: https://www.overleaf.com/latex/templates/infographics-cv/hdgkztmhztph

Contributors should have a space where they can define their bio, to serve as a small CV to be added as a backmatter of the book, along with the author's information and forward links.

The bio should be one or two small phrases. I'm thinking of letting every contributor to pick one or two single graph resource and then put arbitrary information for it - but the space should be relatively small.
Besides this, offer an option so each one can add their contact information, such as steemit user, email, and so on.

It should be possible to fetch the user's steemit bio automatically, if he has given his steemit user info.
This should make it easier that he doesn't have to keep updating this information on this repo itself.

The contribution on my part will only require that a link for discussion on xx.ancap.ch to be listed on the start and end of the mainmatter, as an annonymous footnote. It doesn't have to be the only nor the first recommended place for discussion and questions.

Moved from ancap-ch/from-en#1629

Create a script that analyzes each phrase simultaneously between the original and translated markdown files. It should use environment marks to be able to create "chunks" of strings that are very likely to be correlated.

For a start, it would be useful to have the translated text in one column, and the original in the other. Then when some texts inside one chunk is selected, the other column follows, in order to show that chunk as well.

Then only the translated should be editable, and then the modifications should be shown and be able to be save on the original file.

Most of it will probably be javascript, but the file creations can be done in Rust.

That can be a specific target output as well.

Can be used: https://crates.io/crates/difference
also see: https://crates.io/crates/seal

Moved from ancap-ch/from-en#982

Some chapters have static footnotes, referencing the original publication. This will be added later, somehow

Moved from ancap-ch/from-en#4

Underscore has problem to render in the engine. Fix it somehow, and test it inside URLs.

Moved from ancap-ch/from-en#36

The XeLaTeX expression
$ Y = a + b_1 \textbackslash log X_1 + b_2 X_2 + e $

resulted in:

which is the wrong intention. Should replace the "\textbackslash" by "\"

Moved from ancap-ch/from-en#1481

The DroppedCapital letter, at start of texts, can overlap the next paragraph if the first is too small:

It is needed for the script to verify, and try guessing if it's a small paragraph. If it is, one or two line insertion
at the beggining of the next paragraph should do it.

Moved from ancap-ch/from-en#996

Moved from ancap-ch/from-en#2

Different paper sizes requires different title arranging (line-breaking, etc).
So a optional paper-specific title (including its arranging) should be allowed and used if available.

from ancap-ch/from-en#2195

Moved from ancap-ch/from-en#585

Moved from ancap-ch/from-en#582

Moved from ancap-ch/from-en#3

For now, underscores are disabled.
It is expected to be ignored by the markdown parser, so it won't make urls stop working.
Also, all emphasis should be like this (asterisk)

As seen in the image, different paper sizes would require a specific image cropping so that it will fit in such paper.

From ancap-ch/from-en#2193

As seen in the image, in the bottom of the first page, the iv is cropped (because the page has ended).

Similarly,

The lettrine usage is messed up.

Moved from ancap-ch/from-en#2194

Moved from ancap-ch/from-en#584

• id
  • eepp (15-fev-2018)

Moved from ancap-ch/from-en#1026

So far XeTeX is being used to render the pdf output files.
Microtype's Prostusion (margin kerning) feature is used, but Expansion (proper interword spacing) is missed.

But some form of XeTeX's ucharclasses ( https://github.com/Pomax/ucharclasses ) will be needed.
Must search for further options.

pdfLaTeX and also LuaTeX can be used, since ucharclasses can be avoided with the usage of https://github.com/greyblake/whatlang-rs - Rust itself.
So each language should have a priority tool (pdfLaTeX, LuaTeX and then XeLaTeX, for example).

It can be safe to test entire paragraphs, or just smaller blocks of words, or maybe even a character.
I think the script (instead of the language) has a high priority, but this should be researched and tested.

The testing of the commands groups on the templates should take place, to separate tool-specific commands.

For the case of english, if pdfLaTeX is used, lot's of microtype's features can be safely used, which should improve the reading experience.

Other TeX tools could also be used, for example, in the case of Japanese.

Moved from ancap-ch/from-en#1627

Some covers may be worked by custom needs, and may be opted to be pré-rendered as a static image, so an option to use it and skip the text rendering is needed

Moved from ancap-ch/from-en#1217

It is planned to eventually move to Github, so more texts can be added and the languages remain with a large time window to do translations and proofreading free of cost.

It's easier to organize insertions, and to have a coherent team of people working on the same book/essay project.

But more tools will be needed to facilitate contributions proofreading, and the workflow must be as simple as possible. With an organized team workflow (when you know what text you're working on, and others also know that), very feel conflict cases will arise.

Moved from ancap-ch/from-en#983

One japanese character is outputting as a squared F: 􀀀

Moved from ancap-ch/from-en#42

User gn-ahmad reported that putting that character would mess the writing for Persian/Farsi.
So it's better to also consider those as footnote definitions.

Moved from ancap-ch/from-en#1321

• book:

  • A4paper for print [WIP]
  • letterpaper for print
  • ebook
  • ebook mobile
  • epub
  • html

• article:

  • A4paper for print
  • letterpaper for print
  • ebook
  • ebook mobile
  • epub

• The book format has parts (book parts) possibility, article has not.

• The book format has full page covers for all formats, where article only has full page covers for ebook mobile and epub.

• For printing documents should be double-faced (asymmetric margins), where ebook type, for being electronic only, is considered single-facing.

• Electronic formats doesn't need to have a table of contents, since this information can be shown by almost all pdf/epub file readers.

• Ebook targets tablets and PCs, with small margins but still around 66 characters per line; Ebook mobile should have even smaller margins, and around 45~50 characters per line; Epub doesn't have that (it's adjusted automatically).

• A4 paper is the most commonly used papersize, so should be more accessible; letterpaper is the most common on various countries. Supporting both would mean virtually supporting all of the cheap paper available for anyone.

Moved from ancap-ch/from-en#1630

The image offsetting and cropping is done via tex primitives. This means the output pdf file is bigger than necessary.
It's better if the program does this and replacing the file itself. Then the TeX template will be simpler, and the output file will be smaller.

For now, the actual file size will have to be passed as information to TeX. But after this issue is resolved, we can treat the zero number (for dimensions) as "all of the remaining". This would make the info files simpler.

Before closing, needs to deal with the zero dimension (for automatic dimensioning based on the maximum of the required minimum) setting.

Moved from ancap-ch/from-en#708

CrowdIn has accepted the documents translation project in their Open Source support program, so this software will adapt to their style.

The difference is, instead of having a root folder for each languages (whether the document is original or a translation), there is an root folder for each language, but only for documents that are original for that language. Translations will be kept in a parallel git branch.

So the possibilities are:

1. 1. have a 'translation-focused' root folder, with each root language folder for original documents with translations in parallel branches.
   2. have a 'build-focused' root folder, with each root language folder for original and also translated documents, with no parallel branches.
2. Only have 1.1

Of course, 1.2 would be build from 1.1: it's just a sync then branch-checkout and then the copying of files.
This can be even more desirable since then building would be completely separated from the translation in the file system, and files are in a different logical organization. And when syncing, modifications can be identified and accounted, so fetch building only occur for the projects that were modified.

Moved fromhttps://github.com/ancap-ch/from-en/issues/954

Create a regex to detect and filter those spaces out

Moved from ancap-ch/from-en#695