View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000077||Cinelerra-GG||[All Projects] Feature||public||2018-12-26 23:31||2019-04-11 17:04|
|Priority||low||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000077: Review for creating a single manual|
|Description||Need a single manual for Cinelerra-gg. Have started combining the cv one with Features5. So far have the plugins/transitions section combined into 3 parts (using libreoffice that created .odt files). A lot of the plugin descriptions that I copied in from cv need review and maybe updating.|
ANDREA PAZ is going to initially review the following Video plugins to see is description is correct and complete:
Blur Brightness/Contrast Chroma key Color 3 Way Color Balance Decimate Difference key Fields to frames Frames to fields
Freeze Frame Gamma Gradient Histogram Holographic TV Interpolate Video Lens ReframeRT
Selective Temporal Averaging Threshold Time average Translate Videoscope
I will add more sections to be reviewed here later. Eventually it would be best to use html instead of pdf (from .odt).
|Tags||No tags attached.|
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"!
Feel free to use the picture, it's really no problem. For such purposes it may be used unsolicited.
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)
trim.png (54,105 bytes)
> 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.
Yes it ok with LibreOffice tables, I can convert it to LaTeX.
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?
@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)
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)
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:
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)
Camera and Projector
Editing (just some of the parts that were copied straight from cv manual)
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!
> 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.
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! :-)|
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).
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)
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:
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.
10 Plugin Effects - this is a very long one that Andrea worked on
11 Transition (in with 10)
12 Overlay Mode with Porter Duff
To download and look at keyin:
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.
How does a Wiki format possibly fit in here?
> 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.|
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.|
"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.
Here is an article about it, but only in German. With the help of the Google Translator it can be translated into English.
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.
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?
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.
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.
@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.
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/
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.
Thanks for the useful hint. I will try it out.
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.|
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.
- 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.
|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.
|@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/|
|2018-12-26 23:31||PhyllisSmith||New Issue|
|2018-12-27 00:41||WPFilmmaker||Note Added: 0000382|
|2018-12-27 23:45||PhyllisSmith||Note Added: 0000390|
|2018-12-28 02:36||WPFilmmaker||Note Added: 0000391|
|2018-12-28 02:59||WPFilmmaker||Note Added: 0000392|
|2018-12-30 11:09||MatN||Note Added: 0000443|
|2018-12-30 12:08||Sam||Note Added: 0000444|
|2019-01-03 18:09||PhyllisSmith||Note Added: 0000462|
|2019-01-05 17:09||einhander||File Added: feature5.pdf|
|2019-01-05 17:09||einhander||Note Added: 0000488|
|2019-01-05 19:29||Sam||Note Added: 0000492|
|2019-01-05 20:05||einhander||Note Added: 0000494|
|2019-01-05 20:09||Sam||Note Added: 0000495|
|2019-01-05 20:17||MatN||Note Added: 0000496|
|2019-01-06 08:58||Andrea_Paz||Note Added: 0000508|
|2019-01-06 09:51||einhander||Note Added: 0000509|
|2019-01-09 18:07||terje||Note Added: 0000542|
|2019-01-09 18:53||MatN||Note Added: 0000546|
|2019-01-09 21:12||einhander||Note Added: 0000548|
|2019-01-09 21:22||terje||Note Added: 0000549|
|2019-01-09 21:55||Sam||Note Added: 0000550|
|2019-01-09 22:30||PhyllisSmith||Note Added: 0000551|
|2019-01-10 01:12||terje||Note Added: 0000556|
|2019-01-10 01:33||WPFilmmaker||Note Added: 0000557|
|2019-01-10 01:43||Sam||Note Added: 0000558|
|2019-01-10 02:27||PhyllisSmith||Note Added: 0000559|
|2019-01-10 09:14||Andrea_Paz||Note Added: 0000561|
|2019-01-10 11:31||MatN||Note Added: 0000563|
|2019-01-17 11:35||Andrea_Paz||Note Added: 0000615|
|2019-01-17 12:27||MatN||Note Added: 0000617|
|2019-01-17 13:47||Sam||Note Added: 0000619|
|2019-01-17 15:35||Andrea_Paz||Note Added: 0000620|
|2019-01-18 14:34||einhander||Note Added: 0000627|
|2019-01-19 02:10||terje||Note Added: 0000632|
|2019-01-19 17:41||PhyllisSmith||Assigned To||=> PhyllisSmith|
|2019-01-19 17:41||PhyllisSmith||Status||new => assigned|
|2019-01-19 17:54||PhyllisSmith||Note Added: 0000637|
|2019-01-20 08:26||Andrea_Paz||Note Added: 0000640|
|2019-01-20 18:42||PhyllisSmith||Note Added: 0000641|
|2019-01-27 20:57||terje||Note Added: 0000682|
|2019-01-27 22:22||PhyllisSmith||File Added: table_of_contents.pdf|
|2019-01-27 22:22||PhyllisSmith||Note Added: 0000684|
|2019-01-27 22:42||terje||Note Added: 0000687|
|2019-03-01 03:13||PhyllisSmith||Note Added: 0001047|
|2019-03-01 10:55||Andrea_Paz||Note Added: 0001055|
|2019-03-01 19:07||PhyllisSmith||Note Added: 0001056|
|2019-03-05 21:58||einhander||File Added: feature5-2.pdf|
|2019-03-05 21:58||einhander||Note Added: 0001093|
|2019-03-05 22:56||PhyllisSmith||File Added: TableofContents.pdf|
|2019-03-05 22:56||PhyllisSmith||Note Added: 0001094|
|2019-03-05 23:31||PhyllisSmith||Note Edited: 0001094||View Revisions|
|2019-03-06 20:53||Sam||Note Added: 0001100|
|2019-03-07 08:19||Andrea_Paz||Note Added: 0001101|
|2019-03-08 17:39||einhander||File Added: CinelerraGG_Manual.pdf|
|2019-03-08 17:39||einhander||Note Added: 0001104|
|2019-03-08 17:40||einhander||Note Added: 0001105|
|2019-04-01 21:41||PhyllisSmith||Note Added: 0001290|
|2019-04-02 07:25||Andrea_Paz||Note Added: 0001291|
|2019-04-02 15:27||PhyllisSmith||Note Added: 0001295|
|2019-04-02 18:55||Andrea_Paz||File Added: fullplay.png|
|2019-04-02 18:55||Andrea_Paz||File Added: mask-revision.odt|
|2019-04-02 18:55||Andrea_Paz||Note Added: 0001296|
|2019-04-02 19:33||PhyllisSmith||Note Added: 0001298|
|2019-04-05 08:14||Andrea_Paz||File Added: camera_projector_and_size.odt|
|2019-04-05 08:14||Andrea_Paz||File Added: layout.png|
|2019-04-05 08:14||Andrea_Paz||Note Added: 0001300|
|2019-04-05 09:23||einhander||File Added: 123.png|
|2019-04-05 09:23||einhander||Note Added: 0001301|
|2019-04-05 11:15||Andrea_Paz||Note Added: 0001302|
|2019-04-05 11:26||einhander||Note Added: 0001303|
|2019-04-05 13:02||PhyllisSmith||Note Added: 0001304|
|2019-04-05 14:31||PhyllisSmith||Note Added: 0001305|
|2019-04-05 16:02||Andrea_Paz||Note Added: 0001306|
|2019-04-05 17:36||PhyllisSmith||Note Added: 0001307|
|2019-04-05 17:58||Sam||Note Added: 0001308|
|2019-04-05 21:02||Andrea_Paz||Note Added: 0001309|
|2019-04-07 08:21||Andrea_Paz||File Added: shortcuts_table.odt|
|2019-04-07 08:21||Andrea_Paz||Note Added: 0001310|
|2019-04-07 20:59||einhander||Note Added: 0001317|
|2019-04-08 06:34||Andrea_Paz||File Added: trim.ods|
|2019-04-08 06:34||Andrea_Paz||File Added: trim.png|
|2019-04-08 06:34||Andrea_Paz||Note Added: 0001318|
|2019-04-08 16:12||PhyllisSmith||File Added: masking_rework.pdf|
|2019-04-08 16:12||PhyllisSmith||Note Added: 0001320|
|2019-04-09 16:20||Andrea_Paz||File Added: editing-revision.odt|
|2019-04-09 16:20||Andrea_Paz||Note Added: 0001328|
|2019-04-09 16:25||Andrea_Paz||Note Added: 0001329|
|2019-04-09 16:56||Sam||Note Added: 0001330|
|2019-04-10 22:32||PhyllisSmith||Note Added: 0001333|
|2019-04-11 17:04||Andrea_Paz||File Added: backgound-rendering-revision|
|2019-04-11 17:04||Andrea_Paz||Note Added: 0001345|