My solved file format issues

[Michael Uplawski]

Good afternoon.

This thread is an attempt to accumulate successfully applied procedures in order to avoid or remedy all kinds of trouble with file formats. I have the impression that there are still many “incompatibilities” or “inconveniences” observed, when dealing with the softmaker-owned or any other selection of file-formats that exist for arbitrary purposes. On the other hand I remember to have been able to master many of these situations either with the help of others or by inventing my own recipes. But I do not want to publish a list of such ideas and rather ask around for your “success-story“ or good advice which could be re-used under conditions similar to those that you have encountered.

Here is but 1 rather unspetacular contribution that could mark the beginning of a list of “recipes” :

1. As I cannot print OTF-fonts from TextMaker (Free/Debian Stretch/Sid), I am used to converting any such document to PDF prior printing. This works always.

[Edit: My solved file format issues]

[Alfred]

I am used to converting any such document to PDF prior printing. This works always.

I'm a great fan of converting documents to PDF prior to printing. Since any decent PDF viewer will show you exactly how it will look when printed, this can save you a huge amount of paper and ink/toner.

[Michael Uplawski]

Although the topic should cover more than the PDF-format, here is a script which has served me well a few times.
Explanation: A first PDF-version of a construction plan had to be transferred to a few people for evaluation. The plan itself had been in black and white, but was enriched with some photos and photoshopped pictures (before -><- after) which bloated the file to a fantastic size, impossible to send over the mail-system. I found out, that the pictures where unnecessarily big, even in scale. A procedure similar to the one used in the script had served me to reduce the pictures and to create a new, much smaller PDF, that I could easily share on the net and even print out much faster.

The script runs on an ordinary Linux-system, -ordinary in the sense that Ghostscript should be installed-. It will create 1 picture for each page in a PDF-file. This first step cannot contribute to the reduction of the file-size. It will even produce files that are much bigger than the original document. Much depends on some user-decisions on image-format, color-space, compression and the like and maybe on the pages to exclude from the final result. The difference in file-sizes can be negligible or immense.

Anyway, a PDF which is created from pictures will no longer contain any fonts. A second advantage of the procedure is thus the impossibility to copy&paste content from the final PDF-file. All manipulations would have to be done by use of graphics software... I would not call this “securing the content of a PDF-file against theft”, but rather “showing the finger to those who try”...

The script (read on below):

Code: Select all

#!/bin/bash
#
# prints files to image
# ©2007-2016 Michael Upawski <michael.uplawski@uplawski.eu>
# License-agreement: Modify the file as pleases you; use at your own risk as it
# may do some harm somewhere or not. 
# I forbid use of this script to all agencies of current European governments
# as well as to each one of their paying customers. 

# defaults
TYPE=tif
DEV=tiff24nc
RES=400x400
PAPER=a4
GS=/usr/bin/gs
SCRIPT=`basename "$0"`

USAGE="Syntax:\n\tuser@machine:$PWD\$ $SCRIPT [file0] <file1> ... <filen>\nWill create 1 file converted to $TYPE for each page in any of the input-files.\
\n\tusr@machine:$PWD\$ $SCRIPT <output type> [file0] <file1> ... <filen>\nWill instead create files of the specified output type e.g. jpeg, png, pgm"

if [ "$#" -gt 0 ]
then
	case "$1" in
		tif)
			TYPE=tif
			DEV=tiffscaled24
			shift 1
		;;
		tiff)
			TYPE=tiff
			DEV=tiffscaled24
			shift 1
		;;
		jpg)
			TYPE=jpg
			DEV=jpeg
			shift 1
		;;
		jpeg)
			TYPE=jpeg
			DEV=jpeg
			shift 1
		;;
		pgm)
			TYPE=pgm
			DEV=pgm
			shift 1
		;;
		png)
			TYPE=png
			DEV=png48
			shift 1
		;;
		pcx)
			TYPE=pcx
			DEV=pcx24b
			shift 1
		;;
		bmp)
			TYPE=bmp
			DEV=bmp256
			shift 1
		;;
	esac

	if [ "$#" -gt 0 ]
	then
		for inf in "$@"
		do
			ext=${inf}	
			DIR=`dirname "$inf"`
			if [ "$DIR"=='' ]
			then 
				DIR='.'
			fi
			OUTPUT="$DIR"/`basename "$inf" ."$ext"`_%04d."$TYPE" 
			echo "creating files $OUTPUT"	
			# /usr/bin/gs -SDEVICE="$DEV" -r"$RES" -sPAPERSIZE="$PAPER" -sOutputFile="$OUTPUT" -dNOPAUSE -dBATCH -- "$inf"
			"$GS" -SDEVICE="$DEV" -r"$RES" -sPAPERSIZE="$PAPER" -sOutputFile="$OUTPUT" -dNOPAUSE -- "$inf"
		done
	else
		echo -e "ERROR: No files"
		echo -e "$USAGE"
	fi
else
	echo -e "ERROR: No arguments."
	echo -e "$USAGE"
fi

You can (render it executable, then) run the script once without arguments to see the usage-message.

There are command-line tools to create PDF from several picture-files. As I almost always choose the tif-format for this kind of operation, the libtiff-tools come handy: See http://libtiff.org/ or the packages which come with your linux-distribution.

[Michael Uplawski]

Hey. YOU are not alone.

I am.

So here it comes, my next next nifty file-format tip: Do SVG-graphics in SoftMaker office

Almost, that is... Until this morning, I had been convinced, that Inkscape were unable to correctly convert SVG-images to WMF. As you might know, the SoftMaker Office-Suite does not import SVG-graphics into any of its applications. You have to either pixelize the vector-graphics and import a picture as PNG, JPG, PCX (not even bad) or the like ... or you can try to convert your SVG to WMF. Uniconvertor being not up to the task, Inkscape had been my last resort.

But any recent trials lead to either completely destructed images, halfway destructed images or a clean crash of Inkscape.

Today, I have to assume that my original files were corrupted or that something was misconfigured on my machine. I have no idea, but now, Inkscape DOES convert SVG to WMF. I re-use my screen-shot from my posting in the German speaking forum (separate and recycle!), with Carol, Margo, Ginger and Genya on a WMF-image in TextMaker :
[Edits: Kraut2English conversions]

[Michael Uplawski]

See also Sqlite2DBF

So SoftMaker-Office lets you save PlanMaker files in dBase-format, and you can use the dBase-files as a data-source for TextMaker documents.

As the database can be managed in TextMaker, you can choose one of two ways to add, remove or alter records:

1. Either via the menu-command Tools | Edit Database in TextMaker,
2. or after opening the file *.dbf in PlanMaker.

This is enough to create or manage simple databases. The only inconvenience with the procedure is the user-interface, which is either that of a spreadsheet program or the little database-tool which is integrated in TextMaker. You have to remember that dBase itself is a simple, and nowadays considered outdated, database-format.

Those who wish to combine the database-functionality in TextMaker with a full-blown relational database, configured and managed with SQL or by use of a sophisticated user-interface, must be disappointed. I have though a suggestion.., if you can live with the sqlite3 format for your database.

(Foreign Key statement added for sophistication).
You can convert the sqlite-tables from your database each to a dBase-file, using my sqlite2dbf conversion utility:

Code: Select all

user@machine:~$ export LANG=en_EN.UTF-8
user@machine:~$ sqlite2dbf -h

Usage:	sqlite2dbf -s [SQLite-file] [options]
	or sqlite2dbf [Common options]

Specific options:
    -s, --source [PATH]              SQLite-file to read.
    -c, --config [PATH]              Configuration file for this transformation
    -n, --name [TABLE]               The name of the table from the SQLite-database to convert
    -t, --target [PATH]              Path to the dBase-file to be written.
    -l, --list                       Show the list of available tables and exit
    -o, --out [PATH]                 Use the table-name as file-name for the DBF-result, store output in PATH
        --time [list]                Fields (table-columns) which shall be handled as timestamp values.
        --date [list]                Fields (table-columns) which shall be handled as date-time values.

Common options:
    -d, --debug                      Show debug-messages
    -h, --help                       Show this message
    -v, --version                    Show version and program information

If my database is named “record.sqlite”, I extract the table “records” and write it to “records.dbf” with the following command:

Code: Select all

user@machine:~$ sqlite2dbf -s record.sqlite -n Records

The program answers almost immediately with “Done. Bye.”. And in the current directory I find a new file “record.dbf”
When I connect this database with a TextMaker Document, it works just like with the previous version, that I had written with PlanMaker.

Caveats

1. The conversion of date and time-values is problematic, if you do not know the database well enough to determine the fields, concerned. dBase uses a text-field to store dates, in SQLite three different data-types are possible; hence the --time and --date parameters to SQLite2DBF (see usage-message, above).
2. Views are not transformed to dBase-tables.