 |
Single manual is complete and conversion to LaTeX. Now for improvements, see BT 0000363. |
|
|
MatN: I said it wrong in the previous Note. What worked about the best is (without the Quickstart mod): \chapter*{Appendices} \addappheadtotoc \begin{appendices} \include{parts/Quickstart} \include{parts/Developer} \include{parts/AuxilaryPrograms} \end{appendices} But it has an extra blank page in the actual pdf file. @All: will close this BT "review for creating a single manual" and open a new one "updating the manual" as Andrea suggested. |
|
|
MatN: to remove the double Appendices in the Contents when you add the Quickstart line, you have to remove the \addappheadtotoc line in the Cine...tex file. But in this configuration, you lose the Appendices entry in the left hand side tab window shown in the pdf file. Andrea: I like the idea of closing this and opening a new one but I ran out of time today. How do we proceed from here? The easiest thing for me is to keep the 2 git areas in synch some how by my checking into the cinelerra gg one as new stuff comes in. That means if you want to work on, for example, the Developer.tex file, please check to see which git area has the latest. More later. |
 |
Using the tips from einhander to change the TexStudio command makeindex, and then running Tools->Commands -> makeIndex, I now get a nls file, and after then building with TexStudio the Glossary (about 10 pages) is there, both in TOC and after the last appendix. It turns out that before this in the log file there was a complaint about a missing .nls file, this was the problem thus. I did get some blank pages, which I got rid of by changing in the main .tex file the documentclass to "oneside" . |
|
|
If I use that appendix line in the beginning of Quickstart.tex, then I get double appendix 'chapters' in the TOC, see screenshot. Which version of TexStudio are you using? Mine (Mint 19.3) has 2.12.6.
Screenshot_2020-01-06_16-29-40-2.png (37,447 bytes) |
 |
@PhyllisSmith: About appendices. We have encountered one of the oldest bugs in Latex. To work around this, insert the \cftaddtitleline{toc}{chapter}{Appendices}{} as the first line of the file (Quickstart.tex) About glossary. The glossary created correctly on my side. I quote my message from ml: To use the glossary, you have to create custom command in texstudio. In brief, go to the preferences and add custom command or edit the existing for glossary. The command: makeindex %.nlo -s nomencl.ist -o %.nls It detailed here: https://tex.stackexchange.com/questions/161304/makeindex-no-nls-file/161381#161381 Remember to use the newly created glossary command after you add a new word in your glossary, and recompile. End of quote P.S. I use latexmk to compile latex with all routine. Here the configuration for it. cat .latexmkrc $pdflatex = 'pdflatex -synctex=1 %O %S'; # $bibtex= 'bibtex8 -B -c utf8cyrillic.csf %O %B'; #$bibtex= 'bibtex8 -B -c utf8cyrillic.csf %O ?a*.aux'; # Custom dependency and function for nomencl package add_cus_dep( 'nlo', 'nls', 0, 'makenlo2nls' ); sub makenlo2nls { system( "makeindex -s nomencl.ist -o \"$_[0].nls\" \"$_[0].nlo\"" ); } |
 |
How do you proceed, from now on, for user contributions? I modify my branch and make the announcement on Mantis BT; then Phyllis examines it and if it goes well does a git pull on hers? PS: I don't see Glossary on PDF too. |
|
|
Now that the translation of the manual into LaTeX is finished, I propose to close this ticket and open another one on tips, contributions and improvements. I already have several proposals. |
|
|
I checked into https://git.cinelerra-gg.org/git/?p=goodguy/cin-manual-latex.git;a=summary the rest of the manual after fixing some stuff and MatN confirmed that it built with pdflatex. There are some small issues and many, many sections that need to be rewritten, corrected, and updated with all of the changes. @einhander Help needed -- I spent literally hours trying to get the word "Appendices" to show up in the correct spot in the "Contents". Instead of showing up before "A Quickstart", it shows up before "B Developer's Section". In addition, the Glossary does not show up. UPDATE - managed to get in "Contents" the word "Appendices" in the correct spot and checked that change in. GG found a solution to add \chapter*{Appendices} and move the \begin{appendices} down. BUT now in the actual document the Appendices pages has an extra blank page after it. |
|
|
Great! I now have all of the pieces and have merged in the einhander git changes from the last couple of days to the cinelerra-gg repository. I am having a small problem with the Appendices but will straighten that out tomorrow (I had computer problems today). |
|
|
Andrea did the Quickstart section and helped with the developer section. It seems I can now build a complete manual, although appendix A appears in the wrong place in the table of content. Attached is a zip with diff from the latest einhander git. Hope this is allright for everybody. 20200112_cin-latex_matn.zip (26,353 bytes) |
|
|
@MatN. Done! Mailed to Phyllis. |
 |
And here is the right file. Are you as bored as I am? By the way, that was my last post on this bug tracker. Good luck!
Windows-overlays_list-2.diff (2,664 bytes) |
|
|
Hello, my dear friends of light entertainment. ;-) Typos: git mv images/pathbay.png images/patchbay.png grep "images/overlays_list" parts/Windows.tex (see attachment) Fun: grep 'your\?s\?' parts/*tex | wc -l
Windows-overlays_list.diff (2,577 bytes) |
|
|
@Andrea, yes certainly you could help. I won't have much time until next Wednesday. I've split the appendix (converted from the .odt file) into three separate .tex files: Quickstart.txt (appendix A in the .odt), Developer.tex (appendix B) and AuxilaryPrograms.tex (appendix C). AuxilaryPrograms.tex is done, mailed it to Phyllis. The Developer.tex is almost done, last paragraphs. Quickstart I have not started on. If you could do that, then it is very easy also to make a Quickstart manual, from the same part. Only a new high level document is needed. |
|
|
With my incredible skills I added 2 new chapters (20 and 21) to my repository in less than an hour. (I'm kidding, they are only 5 pages!!!). Only the appendixes remain, which I understand MatN is doing them (if you want me to do a part let me know...). |
|
|
Added chapter 19 (and also 18 of MatN, although already present in einhander). PS: My problems with Git: I would like to start from the beginning by deleting my local cin_manual_latex folder and then cloning the remote repository. Question: Should I clone my repository or einhander's? |
|
|
@Andrea, I frequently use DuckDuckGo and stackexchange too. I've been to the Wiki via DuckDuckGo, but only specific items , didn't realize it's the whole thing. Thanks for the pointer, I've downloaded the PDF too for offline reference. @Einhander: Many thanks for enumitem link, that has all I need, apparently. I've used/experimented with all 6 I "list" types I gave. Labeling e.g. in the last subsection of the "AuxilaryPrograms" part. But if I want a "naked" list without numbers, or bullets, or bold labels, with no empty line between the items, I have to specialize it, and was looking for the simplest way. So for instance in the developer appendix where I'm working on, I use now: \hspace{2em} \begin{tabular}{@{}ll} pkg.cfg\_vars & prepended to configure\\ pkg.cfg\_params & appended to configure\\ pkg.mak\_vars & prepended to make\\ pkg.mak\_params & appended to make\\ pkg.cflags & added as CFLAGS+=\$(cflags) to pkg.vars\\ pkg.cppflags & added as CPPFLAGS+=\$(cppflags) to pkg.vars\\ \end{tabular} which gives me an appearance very close to the .odt file output. Thanks also for the % explanation, and about the { } braces. Very familiar to me (I was a C programmer before retiring). |
|
|
@MatN: >Regarding renaming "instalation.tex" to "installation.tex", the chapter label in "installation.tex" is also is named "instalation". If that is changed too it must be changed also in "introduction.tex" where it picks up the chapter number (line 136 or so). Thank you I fixed it, and also set links to corresponding chapters. |
|
|
@MatN: Only a few of them is actual lists: \begin{enumeration} - list with numeration. \begin{itemized} - bullet list. \begin{description} - list with description. \begin{labeling} - special environment used in KOMA-Script class, extended version of description environment. \begin{lstlisting} - not a list, it's used to print source code or similar text. \begin{tabular} - it's used to create tables, not a list. >What is the difference between \begin{description} [noitemsep] and \begin{description} [nosep] , also for enumerate? nosep used to remove all vertical separators, noitemsep used to remove only separators between items. See http://www.texnia.com/archive/enumitem.pdf for details. > Why is there a percent sign '% 'in most places a % behind \subsection like \subsection{FFmpeg Video Plugins}% A percent sign is used to comment your code, latex skip that rest of the line after a percent sign. So, a percent sign is used to skip newline sign. Latex replace one newline sign with one space and if we don't need an extra space we comment it out. For ex.: \subsection{FFmpeg Video Plugins} Some Text. Latex internally converts to \subsection{FFmpeg Video Plugins} Some Text. And \subsection{FFmpeg Video Plugins}% Some Text. Will be \subsection{FFmpeg Video Plugins}Some Text. But in case of \section command it does nothing special. >If you want to change the item in a description list not to be bold, and use the \renewcommand{\descriptionlabel} for that, is that change then active for the rest of the document? If not, until when is it active? If you want to change it back to the default, how can you do that? >Is there general method to do this, e.g. if you have changed picture caption position, how do you set it back to what it was? Or a method to make such a change very localized? In general you a changes can be localized if used inside environment or inside { } braces. We are using enumitem package to extend list functionalities, and the it documentation sure has an answer to your question about description list formatting. (Feel free to ask if you can't find an answer there). >Some of the list type command accept parameters, e.g. [nosep], or \begin{lstlisting}[numbers=none,xleftmargin=10mm] . Where can these be found? Is there a complete reference somewhere? As I've said earlier we are using enumitem package and it's documentation located at https://ctan.org/pkg/enumitem?lang=en. Every latex package documentation located at ctan.org. Also there is plenty of howtos in internet. |
|
|
You probably already know the official documentation: https://en.wikibooks.org/wiki/LaTeX Not being too thorough, I often resort to DuckDuckGo and almost always find the answer in tex.stackexchange.com. For example the difference between [noitemsep] and [nosep] is clarified in: https://tex.stackexchange.com/questions/10684/vertical-space-in-lists But the best thing is to ask Andrey who knows the language deeply and also Olaf. I leave it to them to your questions because I'm not experienced enough (I'm more of a manpower!). |
|
|
I have some questions about the various methods of making a list. So far I found: \begin{enumeration} \begin{itemized} \begin{description} \begin{labeling} \begin{lstlisting} \begin{tabular} Apart from tabular, i have not found a good description so far, either online or in PDFs "LaTex2e.pdf" or the "The Not So Short Introduction to LATEX2e" . Is there a full reference somewhere? At the moment, I have the following questions: ============ What is the difference between \begin{description} [noitemsep] and \begin{description} [nosep] , also for enumerate? ============ Why is there a percent sign '% 'in most places a % behind \subsection like \subsection{FFmpeg Video Plugins}% =========== If you want to change the item in a description list not to be bold, and use the \renewcommand{\descriptionlabel} for that, is that change then active for the rest of the document? If not, until when is it active? If you want to change it back to the default, how can you do that? Is there general method to do this, e.g. if you have changed picture caption position, how do you set it back to what it was? Or a method to make such a change very localized? ========= Some of the list type command accept parameters, e.g. [nosep], or \begin{lstlisting}[numbers=none,xleftmargin=10mm] . Where can these be found? Is there a complete reference somewhere? |
|
|
Regarding renaming "instalation.tex" to "installation.tex", the chapter label in "installation.tex" is also is named "instalation". If that is changed too it must be changed also in "introduction.tex" where it picks up the chapter number (line 136 or so). Regarding actual chapter numbers, I think they are only determined by the order in which the named parts are included in the main .tex file. But it is of course necessary that that order matches the one in the introduction. I don´t know if it is possible to retrieve the order (in the introduction) automatically. @Andrea, regarding font, I just did the`sudo apt install texlive-full` as written in the readme.md file, and that works fine (there are few font substitutions). I do see a slight difference in font between an .odt file in LibreOffice and the Latex-derived PDF, but for me it's fine. |
|
|
@PhyllisSmith: I've your changes into my repo and also rename Installation.tex |
|
|
@Andrea: > Git I can't figure it out (git push doesn't work for me). I'm left in doubt about how the organization of the latex document works: If you don't have an official branch next to einhander's, your chapter 18 doesn't appear to me and consequently my chapter 19 is numbered as 18. You also lose the code's correction and structuring that Andrey does in revisions. It's not a latex it's git issue. Latex knows nothing about branches. In brief then you merge two branches git assume that second branch has a newest changes and tries to keep them. If first and second branches has edits in the same part of code it's called a merge conflict and you have to decide that code is correct. In that case you'll have to use diff tool like meld or vimdiff, they will help you track changes. >(git push doesn't work for me). Are you sure that your GH repo is correctly added? >Can you clarify these points for me? >Other question: In the new PC I think I miss the font used in the manual, since it looks different (it's using Cantarell, I think). Can you tell me the correct font to use? I used XCharter font, it's part of Texlive distribution. |
|
|
@Andrea: things are going to be a little messy for awhile. I know Andrey has other work to do, but if you could add Trouble, chapter 18 and the image, to your branch then at least the numbering will be correct. It is attached. After Andrey adds chapter 19, etc. and does any necessary revisions, I will pick it up from his github. I don't know about the font issue. trouble.zip (102,538 bytes) |
|
|
Git I can't figure it out (git push doesn't work for me). I'm left in doubt about how the organization of the latex document works: If you don't have an official branch next to einhander's, your chapter 18 doesn't appear to me and consequently my chapter 19 is numbered as 18. You also lose the code's correction and structuring that Andrey does in revisions. Can you clarify these points for me? Other question: In the new PC I think I miss the font used in the manual, since it looks different (it's using Cantarell, I think). Can you tell me the correct font to use? |
|
|
@Andrea: I am pretty sure the copy gg made is correct. He used Andrey's repo at: https://github.com/einhander/cin-manual-latex @MatN: I agree with Andrea -- feel free to divide sections up in whichever way makes the most sense. A lot better organization is needed as most of the time I was just adding new stuff into Features5 without much thought just to get it documented. And then when merging the CV manual with Features5 to make the .odt, a lot of cut and paste was all that was going on. |
|
|
> "Changing a file name is easy;" git mv [<options>] <source>... <destination> |
|
|
Oops, type in my last note. It should be "Because TextStudio does not search across subdirectories" |
|
|
@Andrea, I use Write2Latex as follows: - I have a git clone directory cin-manual-latex, where I never edit, and do a git pull when needed. - I made a copy of that directory once to cin-manual-latex_matn, where I do all changes and test. - I use the program ¨meld" to compare the directories before I upload a change, and pick up some late changes in the master. - I copy the .ods file to be converted to a temp directory, and let Writer2LaTex do its work there. - I then copy the resulting .tex and .png files to the appropriate directories in my branch. - Using TexStudio on the main file, edit it to include the new part, and in the new part remove \begin{document} and \end{document} and all common stuff at the beginning. - Because TextStudio does search across subdirectories, I use Geany for that, e.g. to see how a particular construct is used. It is then also very easy to do global changes in multiple .tex files. |
|
|
Changing a file name is easy; - Rename the file in the parts directory - Rename the file in the CinelerraGG_Manual.tex Done. In git, there will be one deteled file (instalation.tex) and one added (installation.tex), and one changed (CinelerraGG_Manual.tex), |
|
|
If I'm not mistaken, my branch's mirror was made. We have to mirror einhander's branch instead, because it corrects my LaTex code and structure errors. I mean, the "healthy" base is Andrey's. #MatN Good idea to divide the appendixes into several parts. Actually I'm not sure how to do it; as well as I'm not sure how to change the title Instalation missing an L. Good idea the sections for Chapter 19: I'll put them into practice. |
|
|
Chapter 19 suggestion (for when it is in Latex): Subdivide the Hardware Acceleration part in three clear sections: - decoding/playback (vaapi, vdpau) - encoding/rendering (vaapu, nvenc) - effects (OpenCL, Cuda) |
|
|
I see that in the appendix the first part is actually the quick start guide, and the manual is already having lots of pages. What if it is split in three: - Quickstart Guide (already there) - User Guide (no quickstart in the appendix, no development chapters) - Developer's Guide. How to build the code and documentation. The User Guide would then refer to the other two where appropriate. |
|
|
I'll take a look at the appendices. In total it is 27 pages, maybe a separate part can be made of each appendix. |
|
|
Because of holidays and problems with new PC I haven't gone ahead yet: MatN did chapter 18, I'm going to do chapter 19 right away. There remain the 20 and 21 that are only one page and then the appendixes (quite substantial). |
|
|
@MatN: About Writer@LaTeX settings: I use extra clean article and utf8 encoding, other setting are default. About your suggestions to page and font size settings. \usepackage{geometry} % page geometry \geometry{left=2.0cm} \geometry{right=2.0cm} \geometry{top=2.0cm} \geometry{bottom=2.0cm} \parindent=0.0cm That's fine to me, but I disagree with font size. 12pt is too small for read in smartphone or tablet screen, also it's too small to print a5 size booklet. To prepare a5 booklets we use 14pt size. About paper size, original odt file has a letter size, so I used it in latex, feel free to change it to a4 and I prefer to use a4 size, but it's up to Phyllis. > does LaTex support conditional processing? So that depending on a cmd line parameter or a setting in the main document, it will compile for electronic reading or for printing? It can be done by creating new main file with corresponding settings, but first we should complete the manual, and then review it and change all direct lengths like cm into indirect like em and \linewidth. If it's not enough, LaTeX support various 'if' statements. @Olaf: Thanks for your latter suggestions about preamble and page margins. I'm agree with you that we don't need some packages like mhchem and amsfonts, but I prefer a larger font size and decrease margins due to reasons I wrote above. If we create an electronic and printable versions of manual we definitely should change a font size and margins. @Phyllis: >I hope our making a mirror is acceptable to you. Yes, no problem. @Andrea: About LaTeX warnings. In general warnings not a problem for pdf compilation. For ex.: 'LaTeX Warning: There were multiply-defined labels.' states that some labels used more than one time. 'Overfull \hbox (1.13277pt too wide) detected at line' states that latex can't fit a word to page borde states that some labels used more than one time. 'Overfull \hbox (1.13277pt too wide) detected at line' states that latex can't fit a word to page border. And if first warning leads to broken hyperlink and should be fixed, then the second warning may be skipped. And so on. @All: I hope I answered all questions, if not, feel free to ask. |
|
|
Regarding layout (see Terje's note https://www.cinelerra-gg.org/bugtracker/view.php?id=77#c682), does LaTex support conditional processing? So that depending on a cmd line parameter or a setting in the main document, it will compile for electronic reading or for printing? For electronic reading, blank pages are unneeded, and left/right header info also, and IMHO the big chapter numbers. So there could be from the same document an output PDF for screen (to go with the product and download), and one for printing (download only). |
|
|
@Phyllis, I've sent you chapter "trouble". Indeed very many thanks to Andrey and Andrea which did the bulk of the work. On the chapter for building Cinelerra, there should be a section saying how to do the same for the Latex manual, or maybe a separate chapter somewhere at the end? For instance, git clone --depth 1 "git://git.cinelerra-gg.org/goodguy/cin-manual-latex.git" cin-manual-latex" seems to work. Useful info is in the readme.md file. |
|
|
@MatN: here is my suggestions for anyone to contribute to the manual. 1) make a local version of the part of the manual you want to modify (or the whole thing) 2) as soon as you have changes that you are happy with - even if only 1 sentence, email that part/image/section or paragraph to me for review ([email protected]) Today GG made a mirror copy of Andrey's/Andrea's github in the cinelerra-gg website and this is where I will be checking in changes personally along with the contributions. I intend to keep it updated with their work as they check in there. Because I have time to work on Cinelerra almost every day, it should be pretty quick to get any contributions added in. Also, I use an mgdiff program to easily check changes so if 2 people change the same file, I can mesh them together. @Andrey/Andrea: I hope our making a mirror is acceptable to you. I have a lot of changes I want to do and do not want to interfere with the last few chapters that Andrea might have already started or make a separate branch. There are so many new features that have to be added to the 17 sections already done that I need to put a push on myself. @All: the hard part has already been done by Andrey and Andrea. Making contributions because of their work seems to be pretty easy -- just look at how they set things up and you can easily learn the latex language constructs that are needed to make mods. |
|
|
I think the best thing is to do your branch by cloning einhander's. Your suggestions seem good to me (like Olaf's). We're also waiting for Andrey's opinion. In my experience I suggest to transform as much as possible the odt parts into lists, which in Latex are very comfortable and powerful. |
|
|
@Phyllis, I'm a little confused about when to use numbered lists or not. For instance, in chapter 18 (.odt), just before 18.2 there is a series of steps to do to create a small sample. These clearly need to be followed in sequence, but the steps are not numbers. On the other hand, in 18.1 there is a numbered list for things to include in problem reports. Yet the entries don't have to be followed in that sequence, and some might not been needed. Do you have a policy for this? Also, I noticed that you have after the dot at the end of a sentence two spaces. This is intended, I presume? |
|
|
What's the best way to contribute toe the Latex version of the manual? Should each contributor make a branch of einhander's git, and create pull request? In the long term that would probably be the best, then one person can review all changes. If and when the Latex version gets finished and used, should the git move to where the code is is? Would be nice to include it in the build process. |
|
|
Thanks Olaf, that fixed it. On another note, I found some parts very difficult to read due to chapter indenting; the .odt files are much better. I did some experimenting. If in the beginning of setting.tex you change to: \usepackage{geometry} % page geometry \geometry{left=2.0cm} \geometry{right=2.0cm} \geometry{top=2.0cm} \geometry{bottom=2.0cm} \parindent=0.0cm , and in CinelerraGG_Manual.tex to \documentclass[ a4paper, 12pt, then it looks very much better IMHO and like the .odt version. It does required sprinkling \medskip followed by an empty line at selected places to get the empty line to separate paragraphs, like in the beginning of chapter 18: You can report potential problems, bugs, and crashes to the Cinelerra-GG website at: \medskip \hspace{10mm}\href{https://www.cinelerra-gg.org/}{https://www.cinelerra-gg.org} \medskip Here you can log the problem into the MantisBT bugtracker, or use the forum Q\&A for help from other users, or email the |
|
|
Re: ifier (name{page.1}) has been already used, duplicate ignored
CinelerraGG_Manual.tex.diff (446 bytes) |
|
|
Thanks. I have used Write2LaTeX with the default settings for chapter 18 as test, and can create a PDF using TexStudio. Requires some editing, but I'm new to LaTex. |
|
|
I have warnings when I compile, too, but they don't compromise the pdf. Let's hear what Andrey says. The single "l" in "instalation" is my typo, sorry. I do not use Writer2Latex, but directly the Latex code via Texstudio. From the odf I just copy/paste paragraphs and sentences, which become plain text inside Texstudio. |
|
|
@Andrea, out of curiosity, do you convert the .odt parts using the Libreoffice extension Write2LaTeX? If so, what setting do you use? My default comes up as in the picture attached.
Screenshot_2020-01-06_16-29-40.png (73,513 bytes) |
|
|
Today I built the Latex manual, after git update (the latest change was adding chapter 17). The build gives some warnings, in the log: line 3034: " (./parts/Instalation.texpdfTeX warning (ext4): destination with the same ident ifier (name{page.1}) has been already used, duplicate ignored" At line 3069 the same warning only about (name{page.1}) . I noticed also "Instalation" is written with 1 L (on 4 places in the log), is that from Latex of in the text? If so, is it a typo or on purpose? |
|
|
As for "the manual should be tailored to the new user and designed uniformly. The personal inclinations to this or that theme or window manager should be left out if possible." I agree but as you can see there are a LOT of images to be re-created. Somewhere I read that Adam left out images in the manual because they change so much. We see that here too. On the other hand, we do not want to lose sight of the fact that there are a lot of faithful users from the old days who will be perusing the manual just to get more detail on newer or less obvious features. When I make new images -- which I hope to do after we have a complete Latex version in PDF and which is necessary to get better quality of png for some of the earliest ones -- I will use the Cinfinity icons (I still often just stare at these because they are just so colorful and "pretty") and standard Cakewalk theme that a new user would see since that is the default. We can add an image for each of the other themes and icon sets in the section discussing themes/icons. |
|
|
In my opinion a part of the screenshots should be replaced by some without the partly oversized window decorations of the different window managers. Only what the Guicast can display should be reproduced. It would also be optically advantageous to limit yourself to one or at most two themes. Because the manual should be tailored to the new user and designed uniformly. The personal inclinations to this or that theme or window manager should be left out if possible. |
|
|
Andrea_Paz: "The figure does not take a numbering and therefore does not appear in the List of Figures at the end of the manual." The "problem" with the caption is not really one. Here is an example, what you make out of it is left to you as always. \usepackage{caption}% texlive-doc/latex/caption/caption-[eng, rus, deu].pdf (You have already included the package "ccaption", maybe it works the same way.) \begin{figure}[h] \centering \includegraphics[width=\linewidth, keepaspectratio]{images/TechnicalDrawing.png} % No caption under the illustration while retaining % the entry in the table of figures: \captionsetup{labelformat=empty, textformat=empty} \caption[TechnicalDrawing (cc-by-sa John C. Artist)]{This text is not displayed below the image.} \label{fig:TechnicalDrawing} \end{figure} An alternative with formatted caption: \captionsetup{margin=4em, font=small, format=hang} |
|
|
I am not just saying this to be "nice", but I really, really like Olaf's image in the beginning of Chapter 2 and now I think every chapter should begin with some type of explanatory image so the reader knows what is coming . But everyone is busy with their own work/hobbies so there is only a limited amount of time to improve the manual. Maybe later when all is in Latex format, then we can "summarize all the credits somewhere in the appendix". Personally, I think they just get in the way of reading the material. |
|
|
It looks better all across the line, I think. And as for laziness, I'm waiting for Sam's miracle weapon. After all, it would make work a lot easier if the software could actually deliver understandable translations. |
|
|
For laziness I made the copy/paste of a previous figure without then making customizations. See if it's okay now. I, too, wanted to make a figure without a caption, but there are two drawbacks: The figure does not take a numbering and therefore does not appear in the List of Figures at the end of the manual. I tried to use the \footnote to insert the copyright, but the result was worse than with the caption, at least for me. (Putting the footnote inside the caption makes me an error.) I don't have much copyright experience. I am a collector of comics and in the essays on the subject every figure of vignettes or tables are always accompanied by the claim. But if it's really obligatory or it can be gathered in the appendix, I can't say. We also hear other opinions. https://www.dropbox.com/s/0js49r47s0qu621/CinelerraGG_Manual.pdf?dl=0 |
|
|
That looks pretty good already. A question, why not use the whole linewidth, as I had suggested? Another question, isn't there a more elegant option in latex for the image credits? I mean, I don't insist and the free license should primarily protect the sources and allow others, who have nothing to do with the project, to use them under these conditions. The graphic speaks for itself and the chapter heading is easy to read. There must be a way to summarize all the credits somewhere in the appendix, right? \begin{figure}[h]% b stands for the lower edge of a page, t for the % upper edge, h for the position where the figure % was defined, and p means that the figure is % placed on its own page. \centering \includegraphics[width=\linewidth, keepaspectratio]{images/Fenstergrundposition.png} % No \caption{The basic window position with its components filling the work space.} \label{fig:Fenstergrundposition}% = window default positions \end{figure} |
|
|
I'm sorry, Olaf; I should have known that the inaccuracies were a symptom of problems. Installing MyriadPro fonts, I could see well in Inkscape but then, in Texstudio it was giving problems that I didn't understand. Instead, with your png everything is fine. The link is the usual: https://www.dropbox.com/s/0js49r47s0qu621/CinelerraGG_Manual.pdf?dl=0 |
|
|
@Andrea_Paz, something went wrong, the font (Myriad Pro) was replaced by one with a different width, probably it is not installed on your system. (I have tried some and wanted to use the otherwise excellent Latin Modern Sans, but in Inkscape the font is just creepy.) Until further notice: - http://womentie.de/cinelerra/manual/ngerman/images/Fenstergrundposition-en.png A graphic adapted to the type area and the font size I could still produce if necessary, if these are finally fixed. @PhyllisSmith, in the German version I have exchanged ultimativ against complete. Please don't take everything I write in the drafts literally, the choice of words is a real challenge, which is constantly turned and screwed and often only serves to give a first impression. |
|
|
Done! https://www.dropbox.com/s/0js49r47s0qu621/CinelerraGG_Manual.pdf?dl=0 |
|
|
Just a short update here for easy reading. The FDL Olaf is referring to is: https://en.wikipedia.org/wiki/GNU_Free_Documentation_License I updated the Introduction section to refer to this instead of the GPL since it is documentation instead of software and handed over the updates to Andrea to incorporate. I will be going through the Latex version chapters that Andrea has converted to put in a few new items and to remove any exact wording that was copied from other manuals. It will probably be slow going for me though. @Andrea, I hope you can add Olaf's contributed chapter 2 graphic as it would be an excellent addition and is really needed as an introduction - the english looks fine to me.. I also like the addition of "The Ultimate Handbook" to the first image although perhaps "Ultimate" sounds like too much hubris and would be way too easy to joke about. @Sam, I hope we can also get this translated via WPML for language translations once the Latex version is complete and updated properly. It sounds like that would make it easy to get it translated while still allowing for updates. I just do not understand enough about all of this to know if it is possible to have that format and still leave the original manual in the Latex format. |
|
|
For the introduction of chapter 2 I created a graphic: - http://womentie.de/cinelerra/manual/ngerman/images/Source/chawin.pdf The source is a bilingual SVG, but the English version should be checked (I already have enough problems with my own language). The license is CC-BY-SA and fits the FDL. - http://womentie.de/cinelerra/manual/ngerman/images/Source/Fenstergrundposition.svg (The SVG is not displayed correctly in the Web browser.) |
|
|
I'm glad to hear you've settled this conclusively. The decision on granting of licences is usually made by the author. Licenses for documentation are compared here: - https://www.gnu.org/licenses/license-list.en.html#DocumentationLicenses (Englisch) - https://www.gnu.org/licenses/license-list.de.html#DocumentationLicenses (German) |
 |
Unfortunately I could not answer earlier, yesterday was a somewhat stressful day. The question about the copyright of the user manual was answered by Phyllis. As long as the manual is licensed under the GPL, the copyrights are clear. I just don't know if the Creative Commons license under CC BY-SA 4.0 makes more sense than the GPL, because the GPL is used more for software than for manuals. Does anyone have experience with this? As far as I understand, the CC BY-SA 4.0 is compatible with the GPL license. Does anyone have any idea under which license the user manuals of open source software are usually provided? I only ask out of curiosity. I like your suggestions for the user manual. |
|
|
Contrary to the initial work on the English original, I decided to put all files into a separate directory for the translation (ngerman). As a class for European typography I use KOMA-Script, at least I can read that. It is output one-sided, because it is only read on the screen anyway and so the pages don't jump back and forth anymore. It works with LuaLaTeX. The branch is nevertheless bilingual, which might be helpful in the translation that still needs to be done. The cover page has been redesigned with soft blue as the new friendly color, which will also be used to loosen up text passages such as chapter headings (orange was already taken.) Now a font would have to be selected, whereby a sans serif is to be preferred. I have roughly defined the lettering CinelerraGG in all variants and this could be used instead of the small caps. So far so good. But tomorrow the seriousness of life goes on again. Meaning my time is as precious as everyone else's. A completely professional team of the mailing list is available for the manual, experienced users and professional image designers. Reading tip and source of inspiration: - Der ultimative Leitfaden zu DaVinci Resolve 15 (German) - Avanced Editing with DaVinci Resolve 15 (Englisch) |
|
|
What do you think of the cover sheet? (Don't worry, I don't want to take anyone's work away.) CinelerraGG_Manual-ngerman.pdf (137,683 bytes) |
|
|
> PhyllisSmith: "this pdf file is 423 pages long -- Features5 was 269 pages long" This is mainly due to the font size used as well as the type area and the number and size of the graphics used. Andrea's git-version has 459 pages, designed for European typography there are currently 416 pages. It is considered no proof of anything. ;-) |
|
|
In reviewing the CinelerraGG_manual.pdf (which is the basis for the LaTex manual), I have the determined that very little is from the original manual. As an example this pdf file is 423 pages long -- Features5 was 269 pages long and I can tell you for sure that that is all original work from here. So now in reviewing the other 154 pages, the only similarity is in the sections on: 1) camera and projector and masks -- this is outdated and I plan to rewrite it when time permits 2) sound level meters -- I can easily change this 3) some part of Project and Media Attributes 4) very small parts of keyframes 5) some parts of Configuration, Settings... -- just because you can not change descriptions of parameter values 6) about 5 parts of section 19.6 Usage tips -- for how to do some really old stuff So after I change the above, I will remove references to the old manual and old contributions for clarification. |
|
|
The below is DIRECTLY copied from the cinelerra-CV manual from which I originally drew material. There is no problem. And indeed, before the final CinGG manual is complete, it will be so different from the original, that there is still no problem. Copyright c 2003, 2004, 2005, 2006 Adam Williams - Heroine Virtual Ltd. Copyright c 2003 - 2016 Cinelerra-CV Team. This manual is free; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This document is distributed in the hope that it will be useful, but WITHOUT ANY WAR- RANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA. |
|
|
Sam, you and I are subject to German copyright law, as you surely know. I would like to briefly point out a fact that should protect you from possible damage. Because not everyone can afford to be as relaxed about copyright as, for example, our American project managers. The handbook clearly shows that this is a conglomerate of various existing works. parts/Introduction.tex: „based on the manuals of Adam Williams and the Cinelerra CV Team, as well as many unnamed Volunteers“ For us, the first part that is interesting is the one that comes from Williams. In doc/cinelerra.texi it says: "Version 4.1 by Adam Williams Copyright @copyright{} 2011". All former and current manuals are based on this. This work is independent of the source code, which is under a free license. Williams manuals can in my opinion be classified as copyrighted. Translations of these works are also protected under German law, or a license will be required as soon as translations are published. (Of course everyone may translate the texts, but not publish them, this violates the copyright.) From my amateur point of view, either the written consent of Williams is required, or the text must be rewritten in all relevant passages. |
|
|
Thanks for the hint. Sounds interesting, I'd have to give it a try. |
|
|
> Sam: "In fact it is a challenge to create the English Cinelerra user manual as an HTML document once, after that it is relatively easy to translate it into other languages." #+BEGIN_QUOTE LaTeX2HTML is a conversion tool that converts documents written in LaTeX to HTML format. LaTeX2HTML replicates the basic structure of a LaTeX document as a set of interconnected HTML files which can be explored using automatically generated navigation panels. The cross-references, citations, footnotes, the table of contents and the lists of figures and tables, are also translated into hypertext links. Formatting information which has equivalent ``tags'' in HTML (lists, quotes, paragraph breaks, type styles, etc.) is also converted appropriately. The remaining heavily formatted items such as mathematical equations, pictures or tables are converted to images which are placed automatically at the correct positions in the final HTML document. #+END_QUOTE Hompage: http://www.latex2html.org/ Why don't you try it out? |
|
|
@Olaf The translation tool WPML does most of the work, it is very easy to use. In fact it is a challenge to create the English Cinelerra user manual as an HTML document once, after that it is relatively easy to translate it into other languages. Because no design or formatting is required, everything is done by the WPML tool. But I am also open to other solutions. |
|
|
I just read Sam's proposal to translate the manual: - https://lists.cinelerra-gg.org/pipermail/cin/2019-November/001337.html It's not as simple as Sam imagines it to be, but it shouldn't stop anyone from trying it. What I wanted to say is, I had a little time and I had the beginning of the multilingual document built in. Depending on the language Babel is set to, either the respective translation or the original is used. If this is planned and you don't want to search for it, please let me know. |
|
|
Thanks for the flowers, I haven't done anything with LaTeX for ages. (LaTeX is a wonderful layout program, but when you want something of your own, you sometimes spend days and weeks researching and looking up thousands of manual pages. During this time whole movies are shot.) I think the manual lacks color. Try the following, it works partly. #+BEGIN_EXAMPLE % Redefine Chapters and Sections % https://tex.stackexchange.com/questions/476735/change-chapter-and-section-color-memoir-class \usepackage{xcolor} % define colors \definecolor{chaptercolour}{RGB}{23,85,142} \definecolor{sectioncolour}{RGB}{23,85,142} \definecolor{subsectioncolour}{RGB}{23,85,142} %\definecolor{subsubsectioncolour}{RGB}{23,85,142} \setparaheadstyle{\Large\bfseries\color{sectioncolour}}% \setsecheadstyle{\Large\bfseries\color{sectioncolour}}% Set \section style \setsubsecheadstyle{\large\bfseries\color{subsectioncolour}}% Set \subsection style #+END_EXAMPLE |
|
|
Great job, Olaf. For the structure we hear Andrey; but for the contents why don't you add your branch in order to directly enter the changes on GitHub? They don't need to be approved, any additions are welcome. The same goes for anyone who wants to contribute. Sometimes I get the doubt that users think it's a private matter between me and Andrey (and maybe Phyllis...) where it's better not to put your mouth or anyway ask for permission. Actually, my thoughts are as follows: Every decision is up to Phyllis. Even if she doesn't want to, I'd put her name on the manual (+ AA VV). Andrey is in charge of the structure: he is the one who started it all and gave shape to the project. The labourer is concerned with anyone who has advice and/or time to devote (even just pointing out an off-seat comma...); I am one of them. |
|
|
Hello @Andrea, I toyed a little with your manual. Maybe there is something that interests you. Manual-20191117.diff.gz (26,014 bytes) Manual-20191117.7z (38,758 bytes) |
|
|
Ok, lets go to the mailing list. |
|
|
Hi, einhander Maybe it's better to go to the mailing list to not fill MantisBT. If you don't follow it, let me know here. Same if you think it's best to go on here. |
|
|
Hi Andrea, > 1- to use overleaf I don't have to install latex, do I? Right, OverLeaf is fully web based. > But if I still want to install it, which package should I choose: Texlive? TexStudio? Texlive + Texstudio? To use LaTeX localy you need Texlive + Texstudio. It's a short answer. Long answer is to use LaTeX you need "LaTeX Distribution" (Texlive, MikTeX and many others) and IDE (in terms of software developers). Good LaTeX IDE is Texstudio, TexWorks, Kile and others, you can even write in simple text editor like notepad or leafpad. I suggest Texstudio, but its a matter of taste. All modern IDE has hot keys for often used environments and commands. > 2- Does an empty line mean a new paragraph (with related indent)? Yes, empty line is new paragraph. LaTeX has some rules, basically any latter on keyboard it a latter, if you need to use some formatting or diacritics, you have to use a commands. There some reserved charecters: % - comment, $ - math mode, used to typeset math formulas, & - table separator and some other. \\ - its a line brake without indent and paragraph. > 3- In a bulleted list every item has: \item[...]~\\ What does the ~ mean? Basic bullet list is made like this: \begin{itemize} \item YOUR TEXT \end{itemize} \item[...] it's list with description, \begin{description} \item[SHORT WORD] YOUR TEXT \end{description} Generally [ ] braces used as optional argument for command, they can be omitted. The curved braces { } is mandatory argument that can't be omitted. ~ - is non breakable space, used to combine two words on one line. And finally \\ - its a line brake without indent and paragraph. So my construction \item[...]~\\ is Bold TEXT with description on next line without indent. It's kind of hackish way and not recommended to use. I prefer not to use it, but I'm little lazy to find a correct way. Oh yes, line brake can't be started as a first symbol of line, so I use a space as first symbol. Best solution is add description text without line brake. And start a new paragraph for additional description. > 4- Should the code of the figures be put in the next paragraph to the one where there is the reference to the figure? Then where it appears on the page depends on Latex not by us, right? The code for figures should be inserted after the reference to it. We give LaTeX freedom to insert figure there he want. But if figure location not valid for us, we can force latex to display figure at exact location. See answer bellow . In LaTeX some objects can move around text to fill maximum of page, these objects called floats. The floats may be figures with caption, tables with caption and some other rare objects. Floats give you ability not to think about placement of images or short tables, they automatically placed at best location. > 5- What does [htpb] mean in "Figure"? And what does [width=0.8\ linewidht] mean? The [htpb] means place figure: h - somewhere here, t - at top of page, b - at bottom of page, p - on separate page for floats. And this combination mean place my figure somewhere here, better on top, or if you can't at bottom of page, if you can't place my image there, place it on separate page. You can add ! sign: h! - somewhere here, please. Or you can use H to place figure to exact location. [width=0.8\linewidht] - it optional command to regulate figure width. Possible lengths are mm, cm, pt and variables like \linewidht and \paperwidht, it's width of line and paper respectively. Here you can rotate and crop images, add specific page of PDF, or a whole pdf and many more abilities. > Do I have to choose a width for each figure? No. By default images occupy a full line. But mostly of images will be too big/small for a line. So I use 80% of line for them. I use copy-paste method to put code for figures, so it's no problem. 6- I don't understand image 2.3 of the chapter "window" very well: is the figure divided into several strips by \node? Then each stripe is added to an arrow with \draw? And the sentences before the arrows where they are put? Also the figure is aligned in the center, how does it appear to the right of the arrows? No. I use here Tikz language, it's more complicated than plain latex. It used to crate scientific drawings, but syntax are really like a programming. In short I draw big image to the right and seven small text objects to the left and connected them with arrows. I could try to make a chapter out of overleaf, then submit it to your review and, if all goes well, I could sign to OverLeaf. Do you plan to use local LaTeX installation, or use OverLeaf? OverLeaf is easier to start, but it's harder to maintain in long run. But we can switch from OverLeaf in any time. |
|
|
Hi einhander, Sorry for the delay in answering, but I tried to deepen my knowledge of Latex (to know at least what we're talking about). Looking at the code on OverLeaf (and your explanations) I have some questions to ask you: 1- to use overleaf I don't have to install latex, do I? But if I still want to install it, which package should I choose: Texlive? TexStudio? Texlive + Texstudio? 2- Does an empty line mean a new paragraph (with related indent)? 3- In a bulleted list every item has: \item[...]~\\ What does the ~ mean? 4- Should the code of the figures be put in the next paragraph to the one where there is the reference to the figure? Then where it appears on the page depends on Latex not by us, right? 5- What does [htpb] mean in "Figure"? And what does [width=0.8\ linewidht] mean? Do I have to choose a width for each figure? 6- I don't understand image 2.3 of the chapter "window" very well: is the figure divided into several strips by \node? Then each stripe is added to an arrow with \draw? And the sentences before the arrows where they are put? Also the figure is aligned in the center, how does it appear to the right of the arrows? I could try to make a chapter out of overleaf, then submit it to your review and, if all goes well, I could sign to OverLeaf. |
|
|
Hi, Andrea I agree, first look at OverLeaf is really confusing. Just double click on right side (PDF) to go to real text. If you have a writing permission you can change OverLeaf version of Manual (that's obvious). I think you be able to commit to github repo, but that's needs to be tested. > - Can I write code on the left page? But I don't know Latex. You can write a text with minimum formatting, or edit the existing text (if you find a typo). > - Can I fill a structure already made with text? I don't know how to do it. Yes, that's helps me a lot. Let me describe the structure of document. CinelerraGG_Manual.tex - the main file, it's describes a sequence of chapters and overall settings. | |__parts - folder that contain all chaptes files. | |_ Introduction.tex - the first chapter | |_ Instalation.tex - the second chapter, and so on.tex |__images - directory for all images | |__common - directory for files used to setup additional libraries and formatting Each chapter file (*.tex) consist of hierarchical structure of sections (like styles Header 1, Header 2 ... in LibreOffice). In Latex it is commands \chapter{NAME} \section{NAME} ... Good example of Latex files located in parts folder. In order to create new chapter you have to place new file with tex extension in part directory. Write few words in that file. Write new string in CinelerraGG_Manual.tex after \include{parts/Windows}, for ex. \include{parts/YOUR_FILENAME_WITHOUT_EXTENSION}. And recompile. As a result these words from new file will be at new page. Write a new chapter in that file, for ex. \chapter{ Something } . I can answer your further questions about Latex. - Do I transform a writer document into Latex with write2tex and then paste it into the left page? It's quick and dirty way to do. Write2tex can't figure where to place code chunk or git log messages, because they not differ from main text. So I prefer not to use it. I can give you a writing permission if you register at OverLeaf and write your email. |
|
|
Hi, einhander I don't really understand how OverLeaf works: even if I have write permissions, what can I do? - Can I write code on the left page? But I don't know Latex. - Can I fill a structure already made with text? I don't know how to do it. - Do I transform a writer document into Latex with write2tex and then paste it into the left page? Forgive my ignorance, but I'm afraid my level of knowledge is very low. In any case, there's one thing I can say: You've done a wonderful job! |
|
|
Hello Everyone, I finished chapter 3 (75 pages in total), does someone have suggestions? I also uploaded current version of manual into OverLeaf, so anyone can compile and view current version without installing LaTeX. https://www.overleaf.com/read/gxgzwzshjhjg If someone willing to help, I can add writing permission in OverLeaf to that person. CinelerraGG_Manual-2.pdf (1,774,924 bytes) |
|
|
My revision of "background rendering" (thanks to Sam). Remains "Configuration, Settings, and Preferences" but I am absolutely unable to review it. I'm sorry. backgound-rendering-revision (278,491 bytes) |
|
|
Andrea, I think I am caught up with your revisions. I really, really like the trim.png inclusion and I did include the Cinfinity theme image in the Editing section. I had to laugh at Note 1309 "change "butters" to "buffers"" -- I must have been hungry at the time; and worse than that it was "cut butter"! |
|
|
@Andrea_Paz Feel free to use the picture, it's really no problem. For such purposes it may be used unsolicited. |
|
|
@Sam I've used your cinfinity image(page 1). I can delete it, if you wish. |
|
|
Attached is my review of chapter 6 - editing. Given my little experience and competence, this revision has only small changes. editing-revision.odt (1,422,951 bytes) |
|
|
Andrea: thanks for all of the reviews. I am trying to keep up! - I have reworked the Masks in chapter 3 and have included your suggested corrections + GG's input + my testing. See attached pdf file and review at your leisure. Of course, this will have to change again when the Masking MantisBT issue is worked on, but that is good. - The Shortcuts chapter has been replaced with your "pretty" table version. - Good suggestion on a Glossary and I have started that, but that will be awhile before ready for viewing. - Note 1296 changes are all in locally. - Note 1300 is being looked at next as well as everything after that. - Almost done with MatN fixes that he emailed to me directly, but stuck on resize track stuff. - Also, although I avoided it initially, I am now putting in references to other chapters because I think the chapter numbers are firm now. Before I was concerned about adding something like "refer to Keyframes chapter 8" because I thought I might have to change the chapter numbers if I left something critical out. masking_rework.pdf (148,631 bytes) |
|
|
If you think it's useful, I created a figure to be placed next to the table in ASCII on the trim (6.7.5). It does not replace it, because it does not give as much information, but only serves to have a more immediate and colorful view (I also attach the Calc sheet if you need any changes). trim.ods (16,707 bytes)
trim.png (54,105 bytes) |
|
|
@PhyllisSmith > Is is difficult to create the LaTex? No, it's pretty simple. > if you have to do it again after I make more changes? I have to run oodiff and add changes manually. But it's mostly copy-paste. |
|
|
I attached chapter 15 turned into a table. shortcuts_table.odt (34,789 bytes) |
|
|
I'm sorry, Sam; I didn't mean to rush you. I wrote Cinfinity, but I meant Unflat. Take all the time you need. There is no hurry to change the images, we can easily replace them at any time. I think it's even more comfortable with LaTex. @Phyllis. In the meantime, I would like to report some corrections to the manual: - Pag 175: Explain in a further paragraph that "the Shared tracks also function as the "Adjustment Layers" of other software, allowing you to apply plugins and keyframes but leaving the original track unchanged. - pag 117, row 2: change "butters" to "buffers". - pag 45: change "and bottom right coordinates (X2,Y2)... to "and Width and Height (W,H)"... - pag 94: change "default color to blue" to "default color of pink/orange" and change "white curve" to "pink curve". My proposal: add an additional appendix with the Glossary. For example, I still do not understand the terms: edit; assetts; source; footage; clip; resource; shot; video; media; etc. When to use one or the other? |
|
|
I think the more important thing is consistency. Cinelerra is a very complex video editing program in itself and for newcomers it is overwhelming. Different themes scrennshots just confuse the user. I think it would be better to use one theme and use it consistently. We have to make sure that Cinelerra is easy to use despite its complexity. This also includes simplifying the documentation and bringing consistency into it. I myself neglected the design because of the many other tasks, be it server work or language translation. Personally, it would be important for me to use one design. I'm not primarily concerned that the design comes from me, otherwise it would have been finished long ago. It's all about the user and none of the current themes corresponds to the modern design for software applications. Neophyte would be more like that, but unfortunately it's not perfect yet. My goal is to finish the design by the end of this month. I have to set this deadline otherwise I get distracted by too many other tasks. A little pressure doesn't hurt me. I would suggest Cinfinity Design as a standard, because it was made to protect the eye and to make the software look less complex. It's designed to take out the complexity. |
|
|
Andrea, variety is probably better and a lot of people still use SUV (default) and Unflat. But I think we need more Neophyte as it really pops. |
|
|
"...Also, at some point in time I am hoping to change many of the existing screenshots to be done in the same Cinfinity theme but I do not know if that is a good idea as it will not display the variety." I vote for variety, but if you decide for consistency (cinfinity) let me know that I change the images with Neophyte. |
|
|
Andrea: thanks for your input. Enhanger: I am still making quite a few changes here locally. Is is difficult to create the LaTex? if you have to do it again after I make more changes? |
|
|
Enhander: I will make any new screenshots as PNG instead of JPEG from now on. Also, at some point in time I am hoping to change many of the existing screenshots to be done in the same Cinfinity theme but I do not know if that is a good idea as it will not display the variety. Thanks for the heads up -- I did not know any better so that is why I used JPEG. No, I would not commit PDF file to repository at this time. |
|
|
Hi Andrea Yes it ok with LibreOffice tables, I can convert it to LaTeX. |
|
|
Hi einhander, Can I ask you if it's OK to make tables in libreoffice (.odt) or is it better to make them in CSV or other formats? |
|
|
Hi everyone! @PhyllisSmith thank you for the manual update. To produce good looking manual we have to increase resolution of screenshots, and use PNG for them. Because JPG encoding is not ideal for a text. Another question, do I need to commit PDF file to repository? Or just crate several "release" versions of PDF? 123.png (277,851 bytes) |
|
|
Two more reports on the manual and my review of chapters Camera/Projector and for 3.2.7 on Track size and output size. Given my little knowledge of the Camera and the Projector, the possibility of mistakes is very high. Please check carefully. - Pag 71. Remove "presets" from the "Audio atributes" section because it is a separate section. - Pag 35: Change the left image to a higher resolution one (layout.png). camera_projector_and_size.odt (1,189,611 bytes)
layout.png (53,650 bytes) |
|
|
Andrea: thanks I just downloaded your .odt and will make the suggested changes. |
|
|
- Pag 25; CinX: clarify that Cin 8 bit is also 10 bit for all codecs that support them (except h265 which requires CinX). - Pag 104: Use image "Full Play" not the "old" green triangle. - My revision of the 3.2.4 chapter on Mask. NOTE: Plugin's chapter is not perfect; adds, error and contributes are welcome!
fullplay.png (1,171 bytes)
mask-revision.odt (39,962 bytes) |
|
|
Andrea: thanks for help in reviewing. MatN is reviewing also with a "European eye view" with emphasis on some formatting issues, corrections, misleading information, and need for references from one place to another. A big failure that he and gg both see is that use of terminology that has not been defined yet and needs to be or pointer to another place where it is. You are right about the Shortcuts table as it would most likely be a waste of time. |
|
|
Reading here and there, I've already begun to make notes of some adjustments. Regarding the Shortcut table, I wonder if the libreoffice tables are the right format for the subsequent conversion to LaTex. Maybe it's better in CSV or others? |
|
|
There is now a Cinelerra_GG reference manual that includes all pertinent information from the HV Original manual and CV community manual integrated with Features5 (see March 2019 News for link). Some parts contain somewhat dated wording which was mostly "cut and pasted" in and not checked for correctness. GG is helping me with some of that now but will take forever. I have put all of the chapters and table of contents as ODT files at: https://git.cinelerra-gg.org/git/?p=goodguy/documentation.git;a=tree so that anyone can help review. ALL HELP WELCOME, even if a single letter is incorrect, if you notice it, let me know so I can correct. Hoping to do a lot of corrections before a more usable LaTex version is created for ease of making changes and getting it added to/by Einhander's repo at: https://github.com/einhander/cin-manual-latex Chapters considered to be fully presentable are: Introduction (based on Terje's suggestions for improvement) Keyframes (both Andrea and GG went over carefully to find no glaring errors) Plugins/Transitions (Andrea's expertise and lots of work made this pretty close to perfect) Table of Contents Sections that are in poor shape are (HELP!): Compositing (gg is currently reviewing parts of this) Masking Camera and Projector Editing (just some of the parts that were copied straight from cv manual) Background Rendering Configuration, Settings, and Preferences explanation of some of the parameters and best values Shortcuts is complete BUT wouldn't it be nice if it was made into a table like Andrea made for the Title plugin Attributes (hint, hint)? |
|
|
Of cause, default font is disscussable. |
|
|
@PhyllisSmith, @Sam, @Andrea_Paz Thank You! Phyllis: > The new name agreed upon is CinelerraGG_Manual. I renamed main file to CinelerraGG_Manual.tex > 1) Introduction you have in the pdf file here has Chapter 2 and I have not checked that in yet. It's dummy part made from Features5.pdf. I'll replace it with content of odt file. > Another weird thing is that I intended to put this Table of Contents after the Introduction and before the Chapter 2 Installation. Is that bad? No, it normal. I have plenty of books, that have Intoduction, Foreword, Preface before Table of Contents. But all of them are numberless. I've made these changes in repo. Andrea: I'm big fan of serif type fonts, but I agree that default LaTeX font is too thin. So I changed it to more thicker - Charter font. I hope you'll like it. CinelerraGG_Manual.pdf (272,418 bytes) |
|
|
I'd like to add to Sam's compliments on your great work. A small suggestion (based on my taste, so not indicative): Change the font type (very good for printing on paper) with a more uniform and thicker one, to have a better effect on the screen. For example the family Noto. |
|
|
@einhander Great work! :-) |
|
|
Einhander: Yes, please continue -- what you have looks good with a couple of issues. I should have explained my current methodology earlier so as to not make extra work for you. I checked in to the following the chapters that I feel that I am done with. They are in .odt format if you can deal with that (only because I am trying to get it done quickly). https://git.cinelerra-gg.org/git/?p=goodguy/documentation.git;a=tree The chapters get done and then checked in when they do not contain any glaring errors so are out of order. I know it is kind of weird, but the problem is there is a lot of stuff that I do not know and I have to wait until GG can help with technicalities. One thing checked in that does not go with the manual is the Quickstart - that is already in Appendix. I noticed when creating Features5 that I change things a lot -- that is why LaTeX is going to be necessary so as to not have to check in the whole thing when there is just a sentence or 2 change. Features5 is going to go away because it does not tell users how to do anything - just what is different than the HV/CV so you can not learn from this. The new name agreed upon is CinelerraGG_Manual. 1) Introduction you have in the pdf file here has Chapter 2 and I have not checked that in yet. 2) Attached is the eventual chapters just so you can see what is involved to do yet, BUT I change it as I am working so it is not ready. Another weird thing is that I intended to put this Table of Contents after the Introduction and before the Chapter 2 Installation. Is that bad? TableofContents.pdf (80,669 bytes) |
|
|
Hello Everyone! I created git repo with latex template for Cin manual. Repo can be found here: https://github.com/einhander/cin-manual-latex I also typeset introduction that Phyllis posted earlier and first pages of chapter 2. Should I continue my work to convert existing manual to LaTeX? Result pdf is attached. Feel free to comment. feature5-2.pdf (347,652 bytes) |
|
|
Andrea: thanks for the input and I have added Sketcher plugin/simple Motion Graphics to new features list. I do not have the knowledge of other NLEs so do not know what is important and what is different. Anyone who just glances at this will most likely scan the "Innovative New Features" so anything that we can put there is going to be important. |
|
|
Excellent introduction, my compliments. I ask for forgiveness in advance to always call the same thing back: In "STD Features", or rather better in "Innovative new features" I would put the Sketcher plugin. I know I'm fixed, but I think it's a unique feature that other video editors don't have, just compositing software. |
|
|
As suggested by Terje, I have added a brief overview and import/export availability as well as chapter description to the manual's introduction. You can see the results and critique them at: https://www.cinelerra-gg.org/download/testing/manual_introduction.pdf |
 |
Phyllis: > Terje: good idea to add a "brief overview" including some of the most useful and relevant today ffmpeg / file types -- I will add that. > However, I am done comparing Cin-gg to anything else. I think all that can be said there has been said and it has made no difference. I aggree, tell what Cin-GG can do. So the users can compare what else they want0. There is also a separate "Differences" document for download, although this will change over time (updates?). |
|
|
Terje: good idea to add a "brief overview" including some of the most useful and relevant today ffmpeg / file types -- I will add that. However, I am done comparing Cin-gg to anything else. I think all that can be said there has been said and it has made no difference. The artistic/beautiful icons and gui of Cinfinity and Neophyte will be in the "brief overview" also as well as a general mentioning of updating and modernizing as much as possible. BUT I am kind of waiting for the Cinfinity theme to "wax eloquent". The new web server and MantisBT are keeping a lot of people busy. I was unrealistically hoping to be further along on the Manual by now but with Andrea's help on the highly technical machinations of plugins, I still have to run a lot of the wording past GG and he is always busy with programming code. Before the initial "joining" of the odt/pdf files, even number / blank page additions will be done too. Just to let you know how far along a lot of the chapter that have NOT been checked in, I am attaching my personal draft of the Table of Contents (which will eventually be correctly created by LibreOffice I hope, although I have never done that before). An index would be nice too and that is another thing I have never done. And just as a reminder, that Scribus, LaTex, html formats are still future formats that I hope we can come up with so that future changes for screenshots and text corrections and layout fixes are actually reasonable instead of fiddly. table_of_contents.pdf (63,642 bytes) |
|
|
I think that some people look in the Introduction chapter (and possibly only that) to get a brief overview of what they can master with Cin-GG and/or what are the main differences or new features vs Cin-CV and/or -HV. Therefore I think it would be wise to add a section or two about this already here and point to the relevant chapters for detailed information. (A short note about this might also be useful in the Quick Start Guide). In my opinion the first important thing and crucial for many, is which file types are supported for import and export. Especially if they have experienced limitations with other Cinelerra versions or commercial NLEs with limited free versions. If correct, tell that Cin-GG has FFmpeg implemented (integrated) for input and output and make advantage of directly file converting (pre and post-processing), without the need for command lines to be executed manually on beforehand or afterwards (nothing for novies). The second important thing to mentione in the intro I think is the new plugin icons and gui. ----------- A sub note: I know the available .odt chapters are pre-editions or pre-layout. I exported them to pdf and joined them to a single pdf for two-sided printing on papers (for reading and text marking). Yet, I will suggest already that all chapter counts even number pages, so that text for new chapters in the joined edition always start to the right on a odd numbered page. That is it can be necessary to add a blank last page for some chapters and behind the front page. This will also benefit the later table of content. |
|
|
Andrea: thanks for the review. 1 Even though GreyCStoration is not executable/usable in CinGG, it is still part of the code base in the GIT repository so until it is removed completely, I think it needs to stay in. 2 Fixed locally and will be checked in later 3 Yes, for big noticable things, we should still mention (just like for Blue Banana program and documentation. |
|
|
Three little notes about licenses.odt only: 1- I think GreyCStoration is no longer present in CinGG. Am I wrong? 2- In the description of OpenCV there is an incorrect space (in grey) that probably comes from the conversion of the original pdf. Just delete it and recreate it ex-novo with Space. It's between the sentences: ...purpose are disclaimed. / In no event... 3- Should we mention Olaf for the theme Neophyte, even if he no longer keeps it? |
|
|
All: checked in 5 sections in LibreOffice format (*.odt) of the manual. Should be readable by the standard Office too. All review and comments are welcome. 1 Introduction 10 Plugin Effects - this is a very long one that Andrea worked on 11 Transition (in with 10) 12 Overlay Mode with Porter Duff 21 Licenses To download and look at keyin: https://www.cinelerra-gg.org/git/?p=goodguy/documentation.git;a=summary click on Manual sections... click on 1 of the .odt files and you should be able to download that. @Terje: I also looked at wiki as a format but too high of a learning curve for me at this time. Eventually we can switch to LaTex, Scribus, and anything/everything else! |
|
|
In 2007 there was created a Wiki where registered people could collaborate on revision of the Cinelerra-CV manual. https://cinelerra.skolelinux.narkive.com/HTmQpToX/cincvs-new-cinelerra-cv-wiki-on-cvs-cinelerra-org How does a Wiki format possibly fit in here? |
|
|
@MatN > Is there a LateX expert who can create a layout that more or less looks like the PDF there is now? I'm sure a one-time import of the current text is manageable. I can prepare initial structure, template in LaTeX and prepare git settings for repository. |
|
|
@ MatN. I haven't used MS Windows and MS Office in a long time. I use LibreOffice Writer (and I've been trying very hard to layout my book with Scribus) and I've made my template and also a Document Master; but, for example, the file layout changes when displayed in the Master. But the worst thing is that you have to re-adjust the layout every time there is an addition or a change. |
|
|
@MatN It seems @einhander has some expertise in the field. There are some extensions for LibreOffice that make it relatively easy to create an export to LatTex. |
|
|
Are you using Microsoft word or LibreOffice/OpenOffice? At work, I was always fighting with Word, especially the formatting. In the end, I did everything in LibreOffice. With a good template, and people sticking to it (like not making their own header styles), it worked fine. However, the fact that LaTeX allows everybody to contribute and have individual parts of the text in git is very enticing. Is there a LateX expert who can create a layout that more or less looks like the PDF there is now? I'm sure a one-time import of the current text is manageable. |
|
|
Trying to review a chapter of the manual, I realized how right Einhander is about word processors. Every time you change something, the overall layout needs to be redone; and many other issues. So I only see two solutions: 1- write in the Writer without formatting, inserting images one after the other and doing only elementary formatting. Then, after the final revision, bring everything to Scribus and give the final form. 2- Switching to LaTex. IIn this second case, being a complete ignoramus, I have questions to ask. Can you create a basic structure and then everyone (without knowing LaTex) can insert their own texts without further formatting? How to make a centralized project to which everyone can contribute? |
|
|
@einhandler, I compared the example in you msg 488 with the manual as shipped with the 2018-12 release. It takes up 50% more space, and yes, it looks nicer, for a book. But this is not going to be a book to read in the garden. This is a reference manual for a product. And your example wastes space with big chapter numbers. It is not going to help someone looking for information. As long as you can search for and/or jump to sections in the manual it is fine. I´d rather have a simple document in say, courier 10 font, which holds the info I need, than a document with the typographical best fonts/layout/design that misses the information. For me, the current PDF format is fine. There might be better typography via LaTeX, but some things are not better. E.g. the link from your msg 509 shows that LaTeX can use digits which go below the line, like the 9. The compare there is 10 years old, and with MS Word instead of LO Writer (and LO is better). But LO still uses digits which do not go below the line, and personally I find that much better. Can you make the same example that does not use more page space that the original? And digits that don´t go below the line, just to show it is possible? That said, the argument that with LaTeX it is easier to use git is appealing. I´ve installed TexStudio, it looks good, but I have not used it. By the way, are there open source PDF readers under Linux that allow it to jump to a cmd line specified bookmark? That would be handy to extend the Info of plug-ins in much more detail than building in cinelerra itself. |
|
|
The main goal, besides a good result, must be to lighten the workload of Phyllis, Sam and GG. If using Latex guarantees a centralized job to which everyone can contribute by minimizing revisions, then I think I have to take care of learning something new to help. The only danger is losing some contributions from those who do not want or do not have time to learn Latex. I hope other opinions will come in to enrich this interesting debate. |
|
|
@Terje, "I am just curious to know if you so far have utilized LO's "Master Documents and Subdocuments" included its Navigator tool? https://help.libreoffice.org/Writer/Master_Documents_and_Subdocuments" Not yet, but I have split out the sections to about 15 to 20 .odt's so I may have to do something as suggested in the URL. The plugin section which is about ready for prime time after 1 more check by Andrea who added a lot more useful information and screencasts is a little over 100 pages by itself. |
|
|
There are already solutions that use LibreOffice as WYSIWYG editor and export it into a LaTex document. http://writer2latex.sourceforge.net/ Here is an article about it, but only in German. With the help of the Google Translator it can be translated into English. http://www.linux-community.de/ausgaben/LinuxUser/2013/02/LibreOffice-als-komfortabler-Editor-fuer-LaTeX/ |
 |
I always thought LaTEX was used for mathematical formulas, does it deal well with images? I wonder because if it works so good for making manuals and books I wonder why they had to invent DTP software (no sarcasm just genuine curiosity). LO is a "word" processor so I think it should have no issue handling big documents containing only words, if you have several images I suppose it reaches its limit. Having said that version 6 really improved compared to 5, so if you haven't tried it, give it a try. I think having too many people working on one thing might sound good (less work for Phyllis) but in practice too many people can lead to too many ideas for the same thing = confusion. And as Pyllis said we just need one manual. I would propose to create a small team (Phyllis + 1 or 2 people) who can edit it and if others want they can recommend suggestions. Unless we want a wikipeda-style manual with consequent edits wars :O |
|
|
Yes, as usual there are pros and cons with different systems for different use and users, so combining a couple of them may also be a solution as mentioned. @Phyllis, I see the current Feature5 manual counts 252 pages and the Cinelerra-cv manual counts 212 pages. In comparision the LO Writer manual counts 458 pages. I am just curious to know if you so far have utilized LO's "Master Documents and Subdocuments" included its Navigator tool? https://help.libreoffice.org/Writer/Master_Documents_and_Subdocuments |
|
|
I also recently looked around for an alternative format for the documentation - wiki, doxygen in some form, html, and ? The problem with libreoffice is that it does not lend itself to changes and GIT repository. If you make 1 little change, the entire section has to be checked in and that is not good. Also, it makes decent PDF files, but HTML output is unusable. LaTEX would be better for minor changes to check in to GIT, but the more people helping is better and it might be hard. But first WE JUST NEED A SINGLE MANUAL !! If we can just get the initial wording done so users can figure out how to do stuff without looking all over the internet for bits and pieces, then we can switch from libreoffice to something else if it makes sense. Both LaTEX and libreoffice will be around for a long time and each has some advantages. Any other suggestions? |
|
|
@einhander Your suggestion for change or improvement of the current situation, is not wrong and certainly not a wasted time and very much hope that you continue to make good suggestions. I understand your arguments absolutely. @all It is indeed very difficult to let several people work together on one document. LaTex offers some advantages over LibreOffice. I can also understand the arguments for LibreOffice, people don't like to learn something new when they have found a proven tool. LaTex has the disadvantage that you have to learn something completely new and therefore it is more cumbersome to work at the beginning. By the way, I'm in favour of introducing a system that allows us to work on a document at the same time. No decision has been made yet, but I see the need for a simple system that allows people to quickly make a contribution to the documentation, but without having to learn anything new beforehand. Most people like to work with WYSIWYG editors. A complicated system also makes it difficult to be willing to contribute to the documentation. Maybe we haven't checked all the options that are currently available to work together on a document with simple means. I'd like to check it before we make a decision here, also in the sense that people want to translate the documentation into other languages as well. Maybe both wishes can be combined. |
|
|
A tutorial guide .....? Would it be possible to include a worked sample on creating a typical real video without going into every detail for new users? Or should this possibly be a living companion tutorial guide where skilled users add their contributions? What I request is a guide like this for Adobe Premiere, where the tasks and steps are generic, but converted to Cinelerra-GG Infinity? Also included links to video tutorials would be especially useful. https://www.pdfpit.com/view?t=Adobe+Premiere+Pro+CC+2017+Tutorial+-+WillYurman&u=http%3A%2F%2Fwww.willyurman.com%2Fteaching%2Fhandouts%2FPremierePro_Tutorial_Curt.pdf https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=2ahUKEwjz8_vnzeHfAhWKCiwKHcNBCyQQFjADegQIBxAC&url=http%3A%2F%2Fwww.willyurman.com%2Fteaching%2Fhandouts%2FPremierePro_Tutorial_Curt.pdf&usg=AOvVaw0zVVjuk8_dkj7_v5r3NSKI |
|
|
@Andrea, @terje and @MatN You all talk about exchange writings, information, and how cool LO is. But, do you ever try to handle 200+ pages document in LO written by many authors. Its really a pain to merge all versions in one, even if some authors follow style guide. Manual of Cinelerra grows bigger and bigger and its huge amount of work just to maintain it in actual state. Current odt file has is very complex and readability is poor. I proposed you to increase readability and make document less complex, just by change an instrument that produce it. I spent half an hour to write preamble and recreate first 5 pages of manual with LaTeX. Just compare original manual and produced by latex. Code chunks now visible, formatting more solid and its done automatically by latex. Look at another manuals: http://texdoc.net/texmf-dist/doc/latex/memoir/memman.pdf , https://cran.r-project.org/web/packages/ggplot2/ggplot2.pdf and https://mirror.hmc.edu/ctan/macros/latex/contrib/tcolorbox/tcolorbox.pdf Its 500+ pages long, but its easy to write and easy to maintain. I can convert existing LO manual into LaTeX, but if Phyllis is main maintainer of manual it's up to her to decide that instrument to use. P.S. Not so long ago Danny created new good looking site but old community of cin-cv rejected it. I don't want my work to be wasted. |
|
|
I also vote for LibreOffice. Very important is that it is Phyllis´ tool. It is much more important to spend time writing content than learning a new tool set, and having multiple people write independently has its own problem with varying styles etc, so that is not really an argument in favor of LaTeX IMHO. I think it is better that if one has text for the manual, to give Phillis the text and let her do formatting and layout as she prefers. And indeed, it can do a lot more than people give it credit for. |
|
|
I vote also for to continue with LibreOffice Writer, which is a well known wp system for Linux distributions and Linux users. That is more priority on creating and (ex)change content for publishing in html and pdf, than on more advanced DTP tools or Docbook style. With reference to the author Bruce Byfield of the book "Designing with LibreOffice": Especially Writer is a lot more versatile than most users think. People think they’re getting a word processor in Writer, but they’re really getting a mid-level desktop publishing program. Moreover, no other office suite I know of has styles for spreadsheets, slide shows, or diagrams. Writer is a much more advanced tool than MS Word. Calc and Excel are roughly equal. Impress lags behind PowerPoint, especially in support for sound. http://designingwithlibreoffice.com/interview/ |
|
|
@MatN LYX is LYX, it use own format, and convert to LaTeX. You can't get most benefits of plain text format with it, except good looking output text. > I am surprised to see that PDFs from LaTeX are looking better? Surely that depends on the template used in LibreOffice. No, it's very different internally see http://www.rtznet.nl/zink/latex.php?lang=en, it compares ms word and latex, LibreOffice is not far from word. > I'm not sure that having multiple source documents to make one output document is better than having a single source document. It's recommended way to write big documents. Your co-authors can write different parts of document without use vcs. Latex seamlessly joins these parts in one document. In LibreOffice you have to copy-paste these parts and fix fonts, indents an so on. In latex you can compile these parts in totally different template settings without touch of part file. Latex are totally template solution, you can compile one document in different templates. For example for a4 paper and for a5 paper with different chapter styles. > If you have a 300 page manual, can you jump as easily between the various sections in LaTeX is they are in different source files as you can in LibreOffice? Yes, you can, it's basic functionality of latex IDE. > Also, being able to generate proper HTML output is fairly crucial, Latex2html can do it. |
|
|
Sorry to disagree with you. I think we should continue with Libreoffice as long as we are in the phase of exchanging writings and information to which everyone can contribute. When you get to the layout phase then you can use LaTex or Scribus. I'm saying this for my own convenience, I don't want to learn how to use Latex right now! :-) |
|
|
A tool I have used a little for LaTex is LyX, should be in most distributions. Although I don´t see that many advantages compared to LibreOffice, except maybe that diff/patch is easier. I am surprised to see that PDFs from LaTeX are looking better? Surely that depends on the template used in LibreOffice. Numbering is there too, maybe bibliography styles not (have not looked). I'm not sure that having multiple source documents to make one output document is better than having a single source document. If you have a 300 page manual, can you jump as easily between the various sections in LaTeX is they are in different source files as you can in LibreOffice? Also, being able to generate proper HTML output is fairly crucial, I think (even though I much prefer PDF). LibreOffice does this quite reasonable. |
|
|
@einhander Thanks for the useful hint. I will try it out. |
|
|
2Sam For beginners, I recommend a normal LaTeX IDE like TexStudio, it has many useful features (masters for tables and figures), build-in character selector and other things. WYSIWYG editors (like LYX) hides simplicity of original text file and uses it's own file format. For my students I use TexStudio, predefined preamble and couple of snipets for table and figure creation, that's fairly enough for ordinary people to start using LaTeX. Personally, I use Vim with couple of plugins. |
|
|
I like your idea. There are also some tools that support beginners, with a kind of WYSIWYG editor. These tools are by far not as comfortable as LibreOffice, but they make it a bit easier to get started with LaTex. |
|
|
Hello Everyone! I have a proposal to switch manual from LibreOffice to LaTeX as source of for PDF file. Latex has many benefits over LibreOffice: - LaTeX is simple text file, so you can use full power of git on it, including diff, patch and so on. - LaTeX is more close to programmer view, you can split source files into many files and produce one document. Also, you can use any build system to compile LaTeX document. - Pdfs from LaTeX looks more professional than LibreOffice or Word. - It's take care about nubering chapters, section tables and so on. Also if you need to add a bibliography to you paper it has many bibliography styles. - It's fully customizable, LaTeX have many styles of documents. Cons: - LaTeX is programming language, it's pretty simple but it's bit complicated for ordinary user. - PDF is a main output format, although there is some converters to other formats. I attached little demo file, thatI created in LaTeX from manual pdf file. feature5.pdf (206,429 bytes) |
|
|
A git repository for the manual documentation was created by gg this morning. I have added just the Introduction at this time but will be adding more as time prevails. https://www.cinelerra-gg.org/git/?p=goodguy/documentation.git;a=summary |
|
|
We do not intend to drop the PDF document. We intend to offer both a PDF file and the same content as HTML. So the user can choose how he wants to see the information. |
|
|
I hope you don't drop PDF as a format. So much quicker to navigate and search, and a single file. I find it also much better when "reading" instead of looking just one thing up. Put two pages side by side on a 23 inch monitor, it's almost like reading a book. And a PDF can contain external links, and bookmarks. Mat |
|
|
@PhyllisSmith I forgot to say, if pdf format is dropped, can html be viewed offline? (I suppose through the browser) IMHO it is always good being able to access to documentation offline, if online is not possible. |
|
|
@PhyllisSmith Thanks to you for your continuous hard work! My understand is that you do everything with Libreoffice/openoffice and then export as PDF right? That's what "the wrong way to make them fit on the page" made me think. I am no expert but have you thought about using desktop publishing software (DTP)? You just prepare your text in Libreoffice/whateverofficeyouuse, have your photos ready and merge everything in the DTP software. You can move the objects around the page then when you are satisfied lock them so they don't move. Commercial ones are InDesign and QuarkXPress, but there is a very robust and pro software called "Scribus" which I used to dive in for a while. I found it very easy to use (for the basic stuff of course) and it has been used for books and manuals, so I think our case would fit perfectly in the scope of said software. You can find it at https://www.scribus.net/ and at https://wiki.scribus.net/canvas/Success_stories_2017 you can see a list of works made with Scribus. If you never tried I feel to say give it a try, it could really make your work faster and easier. Their dev version is stable enough for use (that's what they say afaik and I never had issues), but be careful because the stable and the dev version have incompatibilities so once you use one version you should stick to that. Bonus: If Scribus turns out to be good enough to produce the manual we can ask Scribus devs to add it to the list of stuff made with it, which would be a good showcase for both FLOSS softwares! |
|
|
WP - thanks for the tip. I will work on higher quality - the low quality was not so much the size of the file, but mostly using the wrong way to make them fit on the page; you motivated be to find a better way! |
|
|
Great idea! If I can make a suggestion (if you plan on doing it) it would be nice having higher quality screenshots. To make them light weight, images can be compressed with open source softwares like https://saerasoft.com/caesium/ or websites like https://tinypng.com/ |
- Anonymous
