What Latex styles do you use and where do you find them?
The reason I'm asking this is that it seems that some 99.9999% of all styles on the internet are copies of each other and of a physics exam paper
However, when you try to find a style for a paper like this one... Good luck, you are never going to find it.
Creating your own style is often not really an option, because it requires you to dig quite deep into the very advanced features of TeX/LaTeX and fighting your way against possible incompatibilities with document classes/packages/whatnot.
LaTeX was originally designed as a reasonably flexible system on which a few standard classes were distributed — that were themselves rather inflexible.
In the current state of affairs, if you want a custom layout, you need to write a few amount of supporting code yourself. How else would it happen? It's not like HTML+CSS gives you templates to work with; you need to implement the design yourself.
Creating your own style is often not really an option
Ah, well, not unless you know how to program in LaTeX!
Seriously, it all depends on knowing where to start and what to build on top of. That catalogue you give as an example would, in my opinion, be reasonably easy to do in LaTeX; it's just a bunch of boxes.
You could write something like
\newcommand\catalogueEntry[4]{%
\parbox[t]{0.23\linewidth}{\textbf{#1}}%
\hfill
\parbox[t]{0.23\linewidth}{\includegraphics{#2}}%
\hfill
\parbox[t]{0.23\linewidth}{\textbf{Characteristics}\\ #3}%
\hfill
\parbox[t]{0.23\linewidth}{\textbf{Application}\\ #4}
}
and use it as so
\catalogueEntry{Spotlights}{spotlight.jpg}
{Eclipse spotlights are...}
{Narrow to medium...}
This is just a basic illustration of what could be knocked up quickly — much more sophistication could be used to turn this into a more flexible system.
I see LaTeX as an extensible markup system. If you separate your markup from its presentation on the page, it's not too hard to get your information represented in whichever form you wish. But getting started is a little tricky, I have to admit; the learning curve for LaTeX programming can be rather steep.
Memoir is a more flexible document class than the default ones, and its manual is excellent.
Well I think CTAN is the best resource for LaTeX and TeX-related stuff. Also lots of scientific organizations provide their own styles, it makes sense to try tracing who was the author/publisher of the paper you like and check their websites.
Related
I am very, very new to Rails development. I have read the arguments against using Rich Text editors that are WYSIWYG. For the purpose of making a CMS for my portfolio site, I can understand RedCloth and implement it.
My question is what happens when there is a lengthy post to be written, how does RedCloth make my job faster? Is there a scenario where Rich Text editors would be preferable?
Pardon me if this sounds ignorant. I want to understand what the best approach is to my situation.
Thank you,
Rishi
just initiated a little pro/cons list of both alternatives, feel free to contribute
WYSIWIG editors
pros:
really easy to set up (check ckeditor and this little gem for instance)
easy to use for anyone able to use Word... to some point
lets you insert any html code / script you want
cons:
the Redcloth site gives sound reasons why you shouldn't use WYSIWYG editors ; among them :
often generates bad, redundant, semanticaly incorrect html code
often lets your users mess up with your site's look and feel by defining their own styles, stuffed in html style attributes
may confuse your users, beacuse they don't know what happens "under the hood", in html ("why can't i just place this picture where i want, in the middle of this page ?")
Textile, Markdown, etc.
pros:
easy to learn, easy to use
usually a good incentive on users to produce semantically correct, structured documents
easy to sanitize, unless you need the html not to be escaped
does not mess with your sites style, unless you allow the user to use advanced features of the format
raw content is readable and well-structured
slightly less storage space needed for raw content
cons:
your users have to learn it, and some don't love it (but WYSIWYG-style UIs do exist to help them ; just look at the good job StackOverflow did with theirs)
for advanced features you have to know the format well
It is a personal choice, you should use whatever you feel is comfortable, especially when you have just started.
WYSIWYG editors are some times not advisable for more advanced users and for making special features, this is because they distance you from the actual source code and force you to work within their frame.
These editors are convenient and quick for simpler work exactly because they give a frame to work in.
Since its not like a code framework or library, you can always make a switch when you are at a point when the WYSIWYG editor you are using is beginning to limit you and get in your way. (only you will know this)
Before then go right ahead!
I'm a member of a group of enthusiast writers, who decided to collaborate on a cookbook-style book for one of programming languages.
We're trying to pick a pipeline for the collaboration.
I like how ProGit is made.
That is Markdown + some custom pre-processing, processed by Pandoc. But I'm concerned that Markdown is too simple for our case.
I look at Sphinx, but I have no experience using it.
I know that LaTeX would work — but I'm afraid that it will scare off the contributors. Also it may be too powerful, and too easy to build a byzantine pipeline if you don't have the necessary experience (which I do not).
Please do not suggest solutions where a person have to write XML by hand or must use some specific GUI (optionally available GUIs are good, of course). Commercial and non-crossplatform solutions are not an option as well.
It's hard to say whether pandoc's extended version of markdown would be too simple for your case unless you say what features you need. Note also that, if you're able to do a bit of very simple Haskell scripting, you can use the pandoc API to add features.
Which one is better and ideal in a web based application?
Edit:
Actually I am developing a community site. So the level of users may vary. Heard about XSS security issues with WYSIWYG editors. Also I am not familiar with WYSIWYM editors and its features. As far as I know the features in WYSIWYM editor is less compared to the other one. I figured one named as "WMD: The Wysiwym Markdown Editor". Its quite easy to use.
So security and ease of usability should be there. In such a situation which editor will be better.
If your users can handle WYSIWYM, I'd go with that.
I'm considering your system will be visual, that is, if you say something is a title it'll look like a title (otherwise the WYS part wouldn't apply). If the user has to manually type markup, then only the most savvy or technical users will be able to handle it.
What I've seen with most users is that they have trouble giving meaning to what they want in a document. They don't think "this is a title", they think "this should be bigger and bold". People that cannot think "this is a title" can't handle a WYSIWYM or they'll find it hard.
Who is going to be your user base? If it's people writing academic papers I'd go with WYSIWYM because they'll have no trouble handling it. If it's for house wives writing recipes, they may not be able to handle it or they'll find it so hard that they'll decide it's not worth the effort.
For me the ideal is WYSIWYM, but do it only if you think your target users will be able to handle it, otherwise you'll have to go with WYSIWYG.
I personally love the WYSIWYM mechanism. I use it for my own work as much as possible. I like it so much that I try to get others to try it too.
Boy, that goes over like a fart in a space-suit.
My cynical self assumes this to mean that most folks are ruined by tools like Word. Everyone knows to make a meaningful document. They also know what a meaningful document looks like. If it doesn't look like that, the tool is wrong! What's actually happening is these document producers don't actually know what they mean, and are used to hiding that fact with pretty borders and adjusting tab-stops.
What I really think is happening, though, is that these folks who are resistant to WYSIWYM are that way because it's a harder way of thinking about something they already invested in learning. This is a level of abstraction above WYSIWYG, though not quite as far removed as composing documents in markup like LaTeX or HTML. And since they can already create any sort of document in a tool that requires no abstraction, it's just a hard sell.
That being said, I think you should force WYSIWYM on your users if that is feasable. There are some good reasons for this
All of the benefits that naturally come with two stage composition. Formatting is not decidable until the document is composed, so any time spent before the document is finished on formatting is time wasted. Get it composed quickly.
The document is marked up with semantic information. This can be used in searches, or for other tasks that strictly visual markup cannot. This is especially useful for accessibility.
By depriving your users of arbitrary formatting decisions, all of your documents will follow company branding. Everything will be in a standard font and color. All text will use the same spacing and height. It will look to readers like it came from a single entity.
Check this
http://www.wymeditor.org/
Could you be a bit more specific? What kind of web application? How many users? Who will the users be?
In general though I've had quite of bit of experience implementing WYSIWYG editors for various CMSs and found them to be quite problematic because clients often like to go wild with formatting their content repeatedly over and over again and often end up having the editor generate HTML of poor quality. This causes all sorts of layout issues or simply pages that look really messy because everyone likes to fancy themselves as graphic designers.
If done properly WYSIWYG can work very well, but it is more work to really get it right, especially when taking into consideration CSS. Most of the good editors are nicely configurable and allow to specify just how much control to give the client over visual formatting.
As for the quality of the code they generate, tools such as FCKEditor and TinyMCE are very mature and do a good job of editing out the irrelevant crud in the source code, but be prepared to provide support for clients using a WYSIWYG when their content doesn't look the way they would like it to.
Since WYSIWYM editors are much like WYSIWYG with structural formatting instead of visual formatting, philosophically I think they are better and less problem prone. So if the client doesn't have a need to visually format the content I think WYSIWYM is bound to cause less headaches down the road.
The editor used here in Stack Overflow is a good example of restrained WYSIWYG. You can format the content visually but only to a certain extent.
If your users a tech savy and understand how the basics of markup go and you think they will feel more empowered using WYSIWYM, then use that. If your application is going to be used to people who have little technical knowledge, use WYSIWYG.
Unless you are doing a tool for print layout (i.e. Indesign or maybe a mailing list printing tool) you are probably better to stick with WYSIWYM.
It is likely to be easier to implement
Web browsers are highly configurable and you may not have fine grained control over items like font size.
The structure is explicit so rendering to different media is comparatively easy.
It avoids the temptation on the part of users to over-design the document or whatever they are entering.
Document structure facilitates indexing, table-of-contents generation and cross-referencing where this is relevant. Compare (for example) maintianing a large index in Word with doing in LaTeX or Framemaker.
Anecdotal experience from LaTeX users (in particular) suggests that organising a document by structure is likely to produce a better document.
From my experience with MYSIWYM, I was very seduced by the idea and the looks, but I was then deceived to know that the editor didn't give me a simple and efficient way to restrict the user, for example the user can insert images inside paragraphs... and I don't want that... I want more control over what the user can do.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
My group uses Literate Programming for most of our source code---this means that internal documentation is written using LaTeX. We have been using PStricks for fancy technical diagrams of the system, but have recently been recommended to use TikZ. I've gathered this information:
TikZ/PGF is new and maintained; PStricks went a long time without a maintainer but has received some maintenance in the last couple of years.
TikZ works with many back ends, including (for those who care) pdftex. PStricks works only with dvips.
PStricks is more powerful and expressive than TikZ. In a dire emergency you even have the full power of PostScript.
PStricks has a significant ecology of extra packages that have been built on top of it; TikZ is too new to have many such things.
TikZ claims to have been designed "with the shortcomings of PStricks in mind." The author does not specify which shortcomings.
I'm interested in the answers to two questions. If you wish, feel free to post one answer per question:
What is the learning curve like for the two tools? (I consider PStricks to have a steep learning curve; about TikZ I am uninformed.)
Considered as programming APIs, is one of these two packages significantly better designed than the other? If so, which is the better design, and why? (What properties does it have that make you consider it better?)
To make a compelling argument why one API is better than another, you may want to resort to examples.
Quick answer: I prefer TikZ to pstricks because I think TikZ
is better designed
is easier to learn
is compatible with pdftex
gives you more power and abstraction (you don't have to specify as many coordinates by hand)
lets you create more beautiful graphics with the same effort
it is easier to extend using TeX programming (it was designed from the ground up with extensibility in mind)
For the users of pstricks, I'd recommend writing all new documents using TikZ in the future. For the users of METAPOST, if their graphics don't use linear equation solving, I'd recommend TikZ. If the METAPOST graphics needs linear equation solving, I'd suggest trying Asymptote.
pstricks does indeed give you the power of PostScript, but it is not PostScript which makes your graphics authoring powerful, but it is abstraction: the use of automatic positioning, automatic intersection calculations, and display style templates. TikZ gives you powerful abstractions, even if you are not a programmer, or you are not willing to program this time.
I don't have experience writing TikZ extensions, but from a quick glimpse of the TikZ source code, it seems to be easy to understand and extend, compared to other TeX macro packages I came across.
As a fond user of TikZ I have been having this debate with a professor in my physics department who loves pstricks and I think we have come to a conclusion as I have stated in other posts. Absent a few times when dipping into the PS itself, TikZ and pstricks are very comparable in most ways. The extensibility and compatibility of TiKZ is appealing leading us to agree that:
We think that new users should learn TikZ.
Old hands at pstricks probably wont gain enough from the switch and may not be worth doing.
Hopefully that helps!
I've only ever used PSTricks, but I've made it do everything I want it to do. Tikz has a great-looking manual and is clearly very powerful. There are two things that I would want out of a drawing system that I can't do with PSTricks: feathered edges (which Tikz can do), and I can't remember the other thing. OP was asking about 'ease of learning': PSTricks certainly requires some trial and error, and I think some coding discipline which I'm not very good at. But \rput is pretty central to how I use PSTricks.. I can't imagine being without it.
On the other hand, 'decorations' look pretty neat. I like the 'saved from trash' example on page 210 (!) of the (560 pp. total) manual. I don't like the fact that Tikz seems to use an entirely different notation -- I don't recognize LaTeX in it which makes it seem foreign and weird. The manual looks beautiful, though. The transparency and 'fade' effects seem very powerful .. can that be done in pstricks? .. but I doubt that I would ever use them. Tikz seems a bit more on the "drawing" end of things. As a rule, I don't make drawings, I make figures.
Can you do arithmetic on coordinates? I'd have to start over and learn from scratch to use Tikz, which is a tough sell if I'm not even sure what I would get out of it.
I am developing an asp.net application working with Miktex distribution installed on the server.
The application will generate math problems and produces pdf files to be downloaded by the visitor. The math problems contain some jpeg images and mathematical diagrams.
I was confused whether to use PSTricks or Tikz. After benchmarking the application, I must use Tikz because it needs only one compilation step using pdftex. So Tikz wins in this scenario. :D
Note: I hope my answer matches your question :D
I think pstricks is superior. TikZ doesn't even have a good way of translating coordinates, like the rput/uput/Aput/Bput pstricks commands. You can use xshift and yshift, but these require units (!), so scaling the image will require manually shaling every xshift/yshift call.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have only little knowledge about LaTeX, basic formatting, basic math fomulae etc.. I found that LaTeX is hard to configure to my own flavor. Recently, I've heard about Docbook, which is also a typesetting mechanism, but much easier since it uses XML. So, if my main job using LaTeX/Docbook is writing a simple document (not a class book) with some mathematics, and I want easy configuration, and a highly constomizable application, which one is better, and is there any good book on Docbook?
DocBook isn't "a typesetting mechanism". DocBook is all about separating presentation from content. DocBook only deals with content; it's used to create an abstract representation of a book, article, etc. There are numerous tools out there which layout DocBook according to predefined templates. Some of these tools use LaTeX. AFAIK, O'Reilly uses a slightly modified version of the DocBook language to author their content, then they feed this XML into custom scripts that integrate with Adobe FrameMaker to layout their books.
LaTeX is essentially an attempt to separate presentation from content within TeX, but it doesn't quite achieve that goal IMO. Presentation is still mixed with the content in most cases. I think LaTeX is currently the best open source tool for laying-out paginated documents. However, proprietary tools like InDesign have many features (like good OpenType support) that TeX doesn't have (XeTeX kind of adds OpenType support). Either way, if you're writing a book, I highly recommend using DocBook to author your content rather than LaTeX.
That said, it sounds like you're writing short, one-off documents with a bit of math. I think LaTeX is probably your best choice. If you need lots of customizability, you might need to use Plain TeX as opposed to LaTeX, but it's going to require quite a bit of work on your part.
Well, I haven't used DocBook, but from a quick look on wikipedia and google:
DocBook does not have elements to describe mathematics.
DocBook is XML, as you say. To me, that makes it a horrible thing to write by-hand (or, rather, with a basic text editor). Maybe you enjoy writing XML, or have a good IDE. I guess you could look at this question.
DocBook's Wikipedia page lists a couple of books on it which you may want to look at, though I obviously can't say whether they are "good" books.
I would suggest going with LaTeX. Get someone to give you a basic template, then writing LaTeX is as simple as:
\section{Introduction}
This is my introduction.
\section{Stuff}
Here is some stuff.
\subsection{Particular stuff}
A particular type of stuff. With maths:
$\int_{x=1}^n 3x^2$
% etc.
Google is your friend for finding basic templates that you can start from:
One
Two
Three
To go from source code to a document, you'll need a working install of LaTeX (which is beyond the scope of this answer, but is pretty easy if you're on linux). Ideally your LaTeX install will include pdflatex. Then you just run:
pdflatex source.tex
(there's a bit more work if you have a bibliography – but that's a topic for a different question)
The great thing about DocBook is that it is XML based - so a chapter is a full subtree, a section is a full subtree, etc. In LaTeX, separation is only determined by the structure of the document during a linear scan.
The worst thing about Docbook is that it is XML based - lower-level stuff is extremely dirty and annoying to code manually.
I'm not really familiar with DocBook, though I have used LaTeX fairly extensively. The idea of LaTeX is not to produce a customized document, it's to produce a readable, attractive document. It's a set of libraries, templates, macros, and so forth around TeX, set up by people who know what they are doing when it comes to document design. Of course, you have special needs that they can't anticipate, so you're going to have to do some tweaking, too. It is a very high-level, declarative language that is meant to reflect the content and structure of a document, rather than what it should look like, the idea being that your ideas and how they are organized is what you should concern yourself with, not the layout of your text on the page. If you need more control, there exists a HUGE library of additional styles and macros and so forth (CTAN), and some of them (memoir comes to mind) give you back a lot of that control.
If you are shoving a lot of complicated formatting stuff into the body of your LaTeX document, you're doing it wrong. What you need to do is get your content in there, and your document structured into chapters and sections and subsections semantically, then go back in and worry about formatting. You shouldn't have to go into the body of your document much at this point; it should all be general stuff that applies to the whole document, preferably in a reusable way. This ensures consistency.
Yes, LaTeX is kind of difficult to configure to produce exactly the kind of layout you want. I suggest you take a look at the manual of the LaTeX class memoir to see what kinds of layouts it enables you to produce.
There is a book on DocBook available online. Take a look at that too, to see what kind of layouts you can produce and if you can easily format the math content you want with DocBook.
My suggestion is to go with LaTeX if you have to write any nontrivial math, but of course it depends on which format you find it easier to work with.
About two years ago, I tried to like and use DocBook; however, I returned to LaTeX because, at least at the time, LaTeX produced better quality output (PDFs). I never managed to get the DocBook to LaTeX to PDF translation working. My problems were likely "operator error", but I suggest trying DocBook (and LaTeX) for a few simple documents before choosing one.
Here are a few points that led me to choose LaTeX:
BibTeX for bibliographies with JabREF as a GUI
Excellent quality PDF output
Lots of examples on the Internet, including several similar to my preferred format
Good books, like "A Guide to LaTeX"
If you like GUIs, take a look at LyX.
The real reasons to use DocBook center on having your document marked up meaningfully, being able to validate it, and transform it for many purposes, not only publishing. LaTeX and other macro sets add a layer of semantic markup, but you're always free to introduce TeX code, and add macros from other sources. Fundamentally, a TeX document is a computer program that can only be parsed by a TeX processor.
For maths and DocBook: DocBook being XML it allows you to use other XML technologies as appropriate; in this case MathML. The XMLmind XMLEditor already mentioned provides a GUI maths editor, and includes stylesheets to format them for web and print along with the DocBook contents.
There are also tools available that enable translation of XML documents into other languages (xml2po is a simple one, http://heartsome.net/EN/home.html is a whole suite).
I don't want to go down the "easier" or better route as I regard this as a matter of taste and getting used to. I see docbook being XML as an advantage as therefore it can be morphed into almost anything you like by using XSLT. Combined with its self-containedness it feels more like structuring content that Latex does. Especially documenting open source software Docbook is really widely used. You can easily grab the templates and stylesheets of e.g. Hibernate and/or Spring and tweak them to your needs.
Another aspect I'd like to spot on is integration in build systems. For Maven there is a plugin called docbkx available, that just spits out PDF, HTML and whatever you like based on the contents and an appropriate XSLT. No further installations needed. The only ways I have seen to get this done with Latex is installing a few packages to the build OS and building your own script around em. IMHO that's not a feasible way to go, especially if you build cross platform.
Regarding the editor I can advise XMLmind XMLEditor that takes a lot of the pain and provides quite a nice WYSIWYG approach to docbook.
If you rely on mathematical expressions I also would rather choose Latex as there is nothing with the same power available in docbook.
FWIW I use docbook via xmlmind (http://xmlmind.com/) to produce html and .chm files. I've also set fop up to produce pdfs, but they aren't pretty.
Having got the docbook source done, I cook it with xsltproc and the docbook.xsl files. This is protracted and painful to set up, but once it's working it's sweet.
Another approach would be to use pandoc (an extended markdown type tool) to get from markdown to DocBook. This would cut the xml editor out, but you still have to do the transformation(s) to your output format.
Whoever had to create a professional, scientific document (research paper, book, technical guide etc.) will know why TeX is a better choice.
For those who are not aware of some facts here is a perfect example: at good colleges student's work may be completely refused if (s)he did not properly reference other people's works. There are, I believe, hundreds of "official" ways for citing and referencing, Harvard school has its own, ACM their own, among computer scientists numeric (Vancouver) notation is the most common. Many professional organisations have their own styles, and they stick to it. As far as I know, TeX is the only typesetting system that is aware of that, and with the help of BiBTeX it becomes extremely powerful tool for authors. It can save hours, if not days, of work.
If I was a novel writer, or author of some non-technical document, I might chose DocBook.
Have you looked at ConTeXt. It is more flexible and much easier to configure compared to LaTeX.
Arbortext supports native LaTeX. You can send the publishing engine or print composer LaTeX and it'll pass it through. It also supports a lot of other composition languages as well.