Help!

Laidout doesn't do what I want! What's up with that?

The huge development team, currently consisting of one (1) person, me, Tom Lechner, can only type so fast! You are more than welcome to post critiques on the Laidout mailing list, flame Laidout in your own personal blog, or get involved with development. Also, you might consult the current Features page, the development Roadmap and also the software comparison page. Just remember that time wounds all heels, er, that is, heals all wounds.

How can I bypass the new document dialog?

You can pass in a few arguments from the command line such as the following. All the ones with the '-n' option create a new document according to your comma separated specifications. If you have spaces in your spec, you should put quotes around it. You can specify the type of imposition (singles, doublesidedsingles, booklet, or net), the paper size (letter, legal, ...), the number of pages, and whether it is supposed to be portrait or landscape:

> laidout --help
> laidout --version
> laidout file1.doc file2.doc
> laidout -n 'letter, 2 pages'
> laidout -n 'net, a4, landscape, 40'
> laidout -n 'legal, landscape, booklet, 44'

default_template blah.laidout

> laidout --template blah.laidout

> laidout -N

Selecting objects seems really screwy. Is this human error, or a design flaw?

Unfortunately, as with previous versions, it remains a temporary design flaw. Selecting multiple objects is rather badly implemented for cases where the objects exist on different pages or layers. Also, when you move a group to limbo, strange things happen when you try to move the group contents around, and furthermore, modifying a group's contents does not cause the group's bounding box to be updated, which is silly. These things will, that is to say should, be corrected by the next release (I know I keep saying that!!). Object selecting should be seen as a quick means to an end at the moment.

I have been putting off making object selection more reasonable until object masking, paths, and more robust object parenting are better implemented, which should be "soon".

I click print, and it says "To file:" or "By command:". Isn't that terribly limiting?

I know it's rather silly to have a 'desktop publishing program' and not have a decent way to send things to the printer, like printing with a certain default DPI and other settings, but what do you want for a 'Version 0.08'? There are many plans for it by version 0.1. If you have Cups, you can "print by command" with "lp" as the command. Laidout creates a temporary postscript file, and sends that to the command. If you print to a file, you could do the same thing manually like this:

lp output.ps

You can preview how it will be sent to the printer with gv:

gv output.ps

It is useful to consult the man pages for lp and lpoptions. You can set up different settings in your ~/.lpoptions file to print at different resolutions, and on different paper. It took me forever to figure that out when trying to print things from Inkscape decently. So for instance if you have the proper line in your .lpoptions file, then you could use it in the "print by command":

lp -d theprinter/matte360dpi

I just pulled out half my hair trying to undo! How can I undo???

It is not advisable to make mistakes. See also this question.

When I export or print documents, how can I tell if Laidout is working, or is just frozen?

Yes, that is a bit irritating, and it is because I have not really implemented progress dialogs yet. In the meantime, you can run a system monitor such as gkrellm. When the cpu box is going full bore, that's probably a good sign.

Why is there such an obnoxious flicker in the windows?

Laidout currently depends on the X Double Buffer Extension being available. If it is, then the windows don't behave like that. To enable that extension, open up your X11 configuration file (usually /etc/X11/xorg.conf), and under Section "Module" area, make sure there is a line that says: Load "dbe". Then, when you restart X, hopefully that will have worked. If you have never done anything with configuring X, then make sure to back up your xorg.conf file before attempting!

What is all that stuff scrolling by on the terminal when I run the program? It slows things down a lot!

That stuff is debugging info written to stderr. The easiest way to get that stuff to go away is to run the program like this:

laidout 2> /dev/null

The harder way to get that stuff to go away is to remember to run make hidegarbage before compiling Laidout. Even before that, you must do the same thing to the Laxkit before compiling it. The precompiled deb package has done this already.

When I choose Net, it's always a dodecahedron. Wtf?

You can save one of those nets, and look at the file. Simply modify the file to have the proper elements, and then load it back in. Bit of a pain, but it works. An eventual feature of Laidout is to have a simple sort of polyhedron unwrapper to speed this up a bit.

Here's a Laidout document of a cube. Make sure there are NO TABS, use all spaces. Data is separated by indentation. The below only has 1 page. You will have to click 'Add Page' 5 times to actually put things on each section:

The "to 3" things define how each faces connect to each other. A cube has 8 vertices, so each of the unfolded net's points map to one of the 8 vertices. In future versions, nets will make much more use of that kind of connectivity information to figure out how pages are supposed to bleed onto each other.

#Laidout 0.08 Document
docstyle
  imposition Net
    numpages 6
    defaultpaperstyle
      name Letter
      width 8.5
      height 11
      dpi 360
      portrait
    net 
      name Cube
      matrix 1 0 0 1 0 0
      tabs no
      points \
        -1 -1 to 0 # 0
        1 -1  to 1 # 1
        1 1   to 2 # 2
        -1 1  to 3 # 3
        -1 -3 to 5 # 4
        1 -3  to 7 # 5
        3 -1  to 7 # 6
        3 1   to 6 # 7
        1 3   to 6 # 8
        -1 3  to 4 # 9
        -3 1  to 4 # 10
        -3 -1 to 5 # 11
        -1 -5 to 4 # 12
        1 -5  to 6 # 13

    
      outline 7 6 1 5 13 12 4 0 11 10 3 9 8 2 7
      line 0 1 2 3 0
      line 4 5
    
      face 0 1 2 3 
      face 1 0 4 5 
      face 2 1 6 7 
      face 3 2 8 9 
      face 0 3 10 11 
      face 5 4 12 13 
page 0
  pagestyle PageStyle
    width 11.44122806
    height 0.8221181412
    pageclips
  layer 0
    visible
    prints

Why are there so many red and green corners all over the place?

Those designate axes for the various objects. Red is the X axis, green is the Y (you can remember this by thinking RGB -> XYZ). The corner is the origin. You can toggle the displaying of axes and/or bounding boxes by pressing 'D' (meaning shift-'d').

Why are there awful ugly ridges in my gradients? They should be smooth as silk!!

The colors in the gradients are currently computed from a linearly interpolated stitching function, which basically means you are stuck with stinking, itchy burlap rather than silk. The adventurous might read up on the postscript specification and modify the outputted postscript files to instead use more arbitrary sampled functions. This is a feature planned for a future version.

Why is path editing all fubar?

Because the interface for editing paths is really, really badly implemented at the moment. You'll have to wait for a future version. Besides, if you are doing anything serious with paths, you should use Inkscape instead, as Inkscape is VASTLY superior to every other path editor I've used.

I just spent 9 hours making layouts with a lot of page bleeding and it prints all wrong! Where can I get a voodoo doll of you to stick things in?

Page bleeding is not implemented properly. The current actual bleeding can be seen in the Paper View mode. This is a big problem for the Booklet imposition, but only if you have bleeding pages other than the centerfold. I am in the process of rewriting impositions to be able to do complex nets and bleed properly, so that bleeding will even wrap properly across net impositions that are derived from polyhedra. You're on your own about the dolls.

Why is Laidout's interface totally unuseable?

The interface works for me! Besides, what do you want for a version "0.08", in the "Mostly does what I want on my machine" stage of development? I mean who uses version numbers like "0.08" anyway? In future versions, the interface will be much more explanatory and configurable. Maybe.

Obviously, the entire interface of Laidout, as well as basically all of its code is experimental. In any case, as time goes on, I will be developing a more formal specification of the Laidout Human Interface and Usuability Guidelines, which will not be referred to as the LHIAUG, because experts say that that acronym is totally unusable, but will be referred to collectively as Ligaments, which refers symbolically to the glue that binds us all together as a species.

A current first principle, or Ligament, is that speed of use and providing all the functions I need to make my art books trump all other concerns, as long as I am the only confirmed developer and user of Laidout. Another Ligament is that programs should be able to start up from scratch in no more than one or two seconds. Some allowance may be made if the document one is trying to open is enormous, but starting the program, even complex, full featured programs, should be very rapid, such as with Blender. Furthermore, control-w is NOT A SUBSTITUTE for control-q!!

I typed in laidout.org and all I got was this lousy website!

It is perhaps worth pointing out that Laidout.org has NOTHING to do with SEX, and that really if that is the sort of thing you are looking for, the first thing you should do is turn off your computer. If you want to talk about something really hot, then let's talk about TeX, bay-bee!