Is this the right place for that? If not, just delete it.
As a (LaTeX) user, I am naturally curious and downloaded the sources. Now the README.md requires the installation of "texlive-full":
LANG=en agi texlive-full
0 upgraded, 109 newly installed, 0 to remove and 13 not upgraded.
Need to get 1787 MB/1798 MB of archives.
After this operation, 2965 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Maybe you still see a way to get rid of this hard drive filling process and omit some unneeded packages?
I also noticed that the lines in the TeX documents are all written without wrapping*. When using Git and Diff, however, hard line breaks could be useful, short lines limited to less than 80 characters simplify the clarity.
*) Supplement: wrapping refers to the usual line break. Just as the younger ones of us know it from their e-mail program.
Hi, Olaf.
I wrote a new post on the mailing list to answer you:
https://lists.cinelerra-gg.org/pipermail/cin/2019-July/000854.html
We have had this topic in the MantisBT and on the mailing list. Here are the links:
https://www.cinelerra-gg.org/bugtracker/view.php?id=77
https://www.mail-archive.com/search?q=latex&l=cin%40lists.cinelerra-gg.org
Finally, the discussion was increasingly on the mailing list.
If you agree, I'll leave this post in here so that other users can also find the hint if they are looking for this topic in the forum.
Yeah, sure, otherwise I wouldn't have done it. In my opinion the separation into three parts and more (forum, bug tracker, mailing list) is too much. The posts in the forum and the bugtracker are visible for interested people and users. After that the activity is measured by those not involved in the development. The mailing list may be interesting for the developers for questions, but it also draws important discussions for the general public into a kind of black hole, despite the search function via mail-archive, another site... What is cleared up on the mailing list has to be repeated in the forum if in doubt, if someone has the time to ask questions - or to reply again (and for others to trump their answers here is a kind of plagiarism, you don't usually do that). And also the password management for the three places, which are managed separately, should not be underestimated. But that is only my opinion, do what you think is right. 😉
I have to agree with you. With the mailing list I am also not particularly happy, it is from a time where still Internet dinosaurs lived. It is indeed to be considered whether we shift this information channel medium-term into the forum. I will start a discussion and a poll. I would prefer to have only two information channels in the long run.
If you're looking for a modern, relaxed template:
https://www.latextemplates.com/ e.g.:
https://www.latextemplates.com/template/the-legrand-orange-book
“At the beginning of a document you are often unsure which settings to choose. With some settings, such as the selection of the paper size, they may already be fixed in advance. But even the question of the page layout may be difficult to answer in advance. On the other hand, this information should also be irrelevant for the author's main activities - drafting the structure, writing the text, compiling illustrations, tables and directories. As an author, concentrate first on the content. Once that is in place, you can take care of the subtleties of the form.” (koma-script/scrguide)
A note on the illustrations. The selected size of the titlebar from the Windowmanger together with the font size should be imo not significantly larger than the icon size and font size of CGG selected. Otherwise you might get the impression that something is wrong with CGG. (Which is obviously true, what the chosen proportions reveal.) This also includes the frame thickness. Since the frame depends on the window manager and does not belong to CGG, I recommend to switch it off for screenshots or at least to reduce it to a minimum.
Have you changed the git url? The last entry is from 2019-07-18. Or is there still vacation (hopefully)?
So I could checkin and not have to bother Andrey continuously and so there is a copy on the website, I am using:
https://git.cinelerra-gg.org/git/?p=goodguy/cin-manual-latex.git;a=summary
I have to be able to make changes so often as the code changes and am going through each word and image one by one to reword all of the lines I copied over from the Secrets/CV manuals to avoid conflicts and convert all png's to the Cakewalk theme for consistency.
The reason for the lines longer than 80 characters is because of the PDF to Latex conversion and copy/paste used to get away from .odt to go to Tex. As I reword some things, I do try to break the lines up though.
Mailing list and Forum and Bug Tracker is like Lions and Tigers and Bears - Oh My! They all have pros and cons but it makes no difference to me. The biggest problem I have with the Bug Tracker is that the discussion gets so long - a bug or a feature is noted, the code gets fixed or changed, and then the discussion goes into fixing something else that is unrelated and I can never close the issue.
I have changed the tables in the file Shortcuts. The dimensions are flexible and adapt to the type area. The text is left-aligned and loosened up and can be entered more easily. Why don't you give it a try, you might like it.
When making replacement screenshots, I will attempt this: "Since the frame depends on the window manager and does not belong to CGG, I recommend to switch it off for screenshots or at least to reduce it to a minimum." Sometimes I deliberately include the frame because it has the window name, like Compositor, in there and I am trying to make it obvious which window it is but it is usually already clear from the commentary.
Andrea did all of the work on the tables and Shortcuts was probably the hardest one to get done so I will let him decide which way to go. I like it the way it is now but if the change makes it more flexible then which ever way Andrea goes is fine by me.
What can I say, you're answering to stuff I wrote over half a year ago. One year ago, in early March 2019, the work on the manual really started. That should be enough time to format a handful of documents and learn the basics of typography, right?
I don't mind the formatting, because I'm using Magit now, and it's not my archive. Git is good at resolving trivial conflicts, and my editor is able to format the text at the touch of a button if necessary after merging, and can also remove the excess spaces and system foreign breaks at the end of a sentence. This can also be automated, but I won't let that be taken away. My editor can do everything, if you know how. Your editor is obviously suitable for writing, which should be enough to make changes to the text quickly.
I didn't mention the screenshots at that time because I like to nag, but because the size of the title list was in no relation to the actual window. That's what I had written. If the context in the document is not obvious or unclear, the placement can be reconsidered and a caption can be added. But to adorn yourself with title bars of popular desktops and give the impression that Cinelerra might work with KDE or Gnome is misleading. It fails already because of the simple transfer of files by an external file manager.
One thing I would like to make clear, when designing a manual I have the user as a target group in mind. It is not about whether you are satisfied with a Word-memory-document (left, right, top, bottom = 2.0cm), but that users can quickly access the necessary information and that they are presented to them in a clear and concise manner. Because the user usually reaches for the manual when he can't get on with his project. And then he wants to have the information without having to search for a long time. 1. The first thing the user notices now is that the last update of the keyboard shortcuts was in January 2019. This date is written above each table and was added manually by the author. This means that the author has already lost the overview of his document. I have replaced it with a meaningful title, which is repeated as headline on every page for this table. 2. The tables are crooked, don't match the type area and the eye has to search constantly. I have corrected this once and for all. The tables are now uniform and grow or shrink automatically with the font size and type area. Surely here and there technical additions can be made, but it is obviously a topographic improvement in objective comparison. Sorry, but if you write "I like it the way it is now" then it shows that you have no idea about it. But thanks for your honest opinion.
I really like your improvements, Olaf.
I put the titles in blue with your code a while back. Everything's OK except for the "\paragraph{}" titles that have gotten too big. (example in chapter 2, 2.2.5 Mask tool; Case 1 and 2; pag 49). I couldn't fix it. You know how to fix it?
I can't tell if it's the document class "memoir", see texlive-doc/latex/memoir/memman.pdf. Why not use a description?
\begin{itemize}
\item Note1: …
\item Note2: …
\end{itemize}
\begin{description}
\item[Case 1, Positive Fade] …
\item[Case 2, Negative Fade] …
\end{description}
% \vspace{3ex}
Or something like that.
@andreapaz, I'd be interested to know how you get your changes to the manual into GG's git after you've effectively abandoned your git archive?
For now to get changes into the manual, send the .tex files to me. The reason for this is because I work on it daily and often in different sections so I might have to merge stuff in. Yes, that is a little inconvenient but as the code changes, I want to get them in the document so that they are known.
The improvements for Shortcuts.tex have been checked in to GIT so now the bad date is gone and it is much easier to read. The fault of the date and small characters came from the .odt file where I was trying to cram in too many characters and avoid 2 lines. I like the CinBlue and CinRed (where will CinOrange and CinGreen eventually be used if uncommented?)
Yes, it is true -- "but if you write "I like it the way it is now" then it shows that you have no idea about it." -- I did not test it yesterday and actually look at the new version.
Also, I redid a couple of images to remove the window manager title bars and will continue to do so. There are so many more improvements needed but I still think that getting the correct information to the users is of the utmost importance -- for example the Camera and Projector section has misinformation in it and is an absolute mess.
#+BEGIN_QUOTE @andreapaz
Everything's OK except for the "\paragraph{}" titles that have gotten too big. (example in chapter 2, 2.2.5 Mask tool; Case 1 and 2; pag 49). I couldn't fix it. You know how to fix it?
#+END_QUOTE
I found the "error", "setparaheadstyle" was intentionally defined that way.
Enclosed is a runnable example with the document class Memoir, which brings color into the game.
Edit: The parental control of the forum does not allow TeX documents, you may have to rename it.
So you had to replace "Large" with "normalfont." Thank you very much.
I don't particularly like the color Orange, nor the title of the chapter with the red number (but you wrote you did it on purpose, so it's fine).
But your suggestions are very nice; why don't you change the "settings.tex" and send it to Phyllis? I can't do that, of course!
_
| |
_____| |
|___| \___
|___|
|___| ___
|__|____/
(my first ASCII art)
Now I wanted to set up the images; advice and proposals on how to set them for the greatest possible uniformity and quality?
"Cinelerra-GG" and "Cinelerra-GG Infinity" as wordmark.
Thanks, the Wordmark was checked into git. (and yes, I misspelled it). I also updated the CinelerraGG_Manual.pdf on the website.
Pull request: Color style is set. Font size normalized and type area set back to that of memoir. images/ from the path of includegraphics removed. Minor changes, see diff.
Changes are checked into GIT (along with a couple of wording changes for other things that I had worked on). One patch set in Settings.diff was rejected so I fixed it by hand so you might want to verify it is correct as my knowledge of patches, git, and latex are only superficial and I do not have time to learn them any better. The lines I believe caused the rejection in settings.tex were:
-\usepackage{AlegreyaSans}
-\usepackage{Alegreya}
These lines are in packages.tex and not settings.tex.
Proposal for the restructuring of the listing.
I like it also EXCEPT I do not like the color for the linux/bash key words like "cd", "env" because it makes me want to click on them like a reference. It emphasizes the words and there is absolutely no reason to. Users reading the manual could care less if "cd" is a key word -- they are just going to cut and paste. But I can live with it if I have to...
Pull request: With main focus on revised listings and the title page. Please have a look at this, changes can still be made.
I like it very much.
