This is a somewhat "advanced" issue.

- What is this "FlowControl" parameter?

Short answer:
------------
It's something which is not strictly needed to
print, but without flow control you can have printer crashes
when printing big jobs (more than 15 pages of normal text,
or just a couple of pages of dithered full page photos
at high printing resolution). If you print a few pages
and let the printer finish the job before sending other
pages, you can work around the problem.  Enabling flow
control will remove this annoying limitation; add to this
that EPL-5700L doesn't work at all if flow control is
off and the printer is connected via USB.

Long answer:
------------
We are a producer of data for the printer, the printer is
a consumer. If the producer is too slow, the consumer can't
work at full speed (less pages per minute); if the host
is too fast, data get buffered into the memory of the printer.
What happens when the memory is full? In a typical situation,
the printer should not accept more data for some time.
But this doesn't happen for EPL printers! The printer
just crashes (or prints garbage).
Luckily there is a solution: we can ask the printer some
internal status and slow down the transfer when the
printer is congested.
This can only be done if we have a *bidirectional*
communication with the printer.

The Unix typical printing system is monodirectional:
jobs are sent to a queue and then they pass through some
filters and the output is finally written to a device
(e.g. /dev/lp0).
Consider this example:
  application -> filters ->   ghostscript    -> device
                            (and ijs server)
which is often done with a pipe similar to this
  application|filters|gs -sIjsServer=OurServer -sOutputFile=-|cat >/dev/lp0

Here an application outputs the job (text, postscript, image),
some filters maybe convert it to postscript, resize, rotate, put 4
pages in one, etc. and pass the postscript data to ghostscript,
which renders an high resolution bitmap and collaborates with
the ijs server to translate the bitmap into the native language
of the printer, which is written to the device.
In this situation the ijs server receives the bitmap from
ghostscript, converts the bitmap description and sends the result
back to ghostscript; the ijs server doesn't talk to the printer
and bidirectionality is impossible.

If the "flow control" option is on, instead, the ijs server
will not send its output back to ghostscript, but drive the printer
directly.
This creates two problems:
(1) the ijs server needs a way to know where the data should go
(USB? parport?);
(2) the pipe should not interfere: if we want to print via parport
the pipe can't be directed to /dev/lp0  because the ijs server would
fail to open the parallel port device.

The solution to (1) is the following.

A special parameter (EplFlowControl) is passed to the ijs server
to tell it what to do with the data. Possible values are:
- "off": (data goes to the normal pipe)
- "/dev/usb/lp0" or "/dev/usblp0" (or lp1, lp2...): communication
happens through the USB lp kernel device. This works if your kernel
supports it ("modprobe printer" could help).
- "libusb": the USB bus is scanned to find the printer and
communication happens through the libusb library. This works
if the kernel has not claimed the printer ("modprobe -r printer"
could help).
- "/dev/lp0" (or lp1, lp2...): same as "/dev/usb/lp0", but via
parallel port kernel device.
- "libieee1284": similar to "libusb" but uses "libieee1284",
for parallel port.

The solution to (2) is the following.

You have to tell the printing system that you want to output
to /dev/null! The /dev/null device will be opened but no data
will actually go there: the ijs server will handle the
data transfer "under the curtains" as specified in the
"EplFlowControl" parameter.

If you're configuring the printer in cups or printconf or
something else, it could be difficult to choose the /dev/null
device. With the cups web interface, for example, it can be done
by selecting "Internet Printing Protocol (http)" and then
writing "file:/dev/null" in the following form. 

Now, what should you choose?
Every option has its own peculiarities.

- With "off", all this stuff is disabled.

- With "/dev/usb/lp0", you need kernel support (usually OK in
most distributions) and correct permissions to /dev/usb/lp*
files (usually OK too).

- With "libusb", you need libusb compiled into
ijs_epsonepl_server (this is OK if you use a precompiled
binary), correct permissions for /proc/bus/usb/00?/00? files
(this is usually *NOT OK* in most distributions) and avoiding
usb printer kernel support ("modprobe -r printer", but sometimes
the module is autoloaded again when you switch the printer
on or connect it to the bus).

- With "/dev/lp0" it's just as with /dev/usb/lp0. Printing
could be slow, sometimes.

- With "libieee1284" you need libieee1284 compiled into
ijs_epsonepl_server (this is OK if you use a precompiled
binary). Printing could be slow, sometimes.

Recommended options are /dev/usb/lp0 or libusb.
The parport ones are experimental at the moment; using "off"
has the limitations we said above.