swfsql / genpdf Goto Github PK
View Code? Open in Web Editor NEW[WIP] usage of LuaTeX or XeLaTeX or Pandoc to generate (non-standard) markdown into pdf and other formats
[WIP] usage of LuaTeX or XeLaTeX or Pandoc to generate (non-standard) markdown into pdf and other formats
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.
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 $
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.
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.
As seen in the image, in the bottom of the first page, the iv
is cropped (because the page has ended).
The lettrine usage is messed up.
Moved from ancap-ch/from-en#2194
Moved from ancap-ch/from-en#584
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
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:
article:
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:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.