Tabellenkalkulation. 1 Lotus Format (WKS/WK1) LOTUS Format (WK3) 53. Die LOTUS Recordtypen der Version 3.

Transkript

1

2 Inhalt Vorwort 15 Teil 1: Tabellenkalkulation 1 Lotus Format (WKS/WK1) 17 Der Aufbau der WKS/WK1-Dateien 17 Recordtypen in Lotus (Versionen 1.1 bis 2.01) 18 2 LOTUS Format (WK3) 53 Die LOTUS Recordtypen der Version 3.x 53 3 Binary Interchange Format (BIFF) 87 Der BIFF-Recordaufbau der Versionen Indizierung in der Tabelle 91 Die Recordtypen im BIFF2- bis BIFF8-Format 91 4 Quattro Pro 3.0-Dateiformat (WQ1) 219 Der Recordaufbau 219 Die Quattro Pro-Recordtypen Symbolic Link-Format (SYLK) 27 9 Die Basis-SYLK-Records 279 SYLK-Formaterweiterungen für CHART Data Interchange Format (DIF) 311 Der Aufbau des DIF-Headers 311 Die DIF-Datensatzstruktur 317 7Super Data Interchange-Format (SDI) 323 Der Header einer SDI-Datei 323 Der Datenteil einer SDI-Datei 327 Inhalt 5

3 Teil 2: Textverarbeitung 8 Word 97-Dateiformat (DOC) 331 Der Aufbau einer Word DOC-Datei 331 Aufbau des Textbereichs 340 Zeichen- und Absatzformatierung WordPerfect-Format 345 Der WordPerfect-Header (Version 5.0) 345 Der WordPerfect-Datenbereich (5.0) 350 Die 1-Byte-Steuercodes von 00H bis BFH 351 Die Fixed Length Multibyte-Steuercodes von C0H bis CFH 354 Variable Length Multibyte-Steuercodes von D0H bis FFH 357 Subfunktionen zur Fontauswahl (Code D1H) 363 Subfunktionen zur Gruppendefinition (Code D2H) 364 Set Group-Subfunktionen (Code D3H) 370 Die Format-Group-Subfunktionen (Code D4H) 376 Die Header/Footer-Group-Subfunktionen (Code D5H) 378 Footnote/Endnote-Group-Subfunktionen (Code D6H) 380 Generate Group-Subfunktionen (Code D7H) 381 Display Group-Subfunktionen 387 Miscellaneous Group 389 Box Group 391 Style Group 395 WordPerfect-Header (Version 5.1) 397 Der WordPerfect 5.1-Textbereich 400 Die Fixed Length Multibyte-Steuercodes (Version 5.1) 401 Die Variable Length Multibyte-Steuercodes (Version 5.1) 403 Subfunktionen zur Fontauswahl (Code D1H) 407 Subfunktionen zur Gruppendefinition (Code D2H) 409 Set Group-Subfunktionen (Code D3H, Version 5.1) 413 Format-Group-Subfunktionen (Code D4H) (Version 5.1) 416 Header/Footer-Group-Subfunktionen (Code D5H) 420 Footnote/Endnote-Group-Subfunktionen (Code D6H) 420 Generate Group-Subfunktionen (Code D7H) Inhalt

4 Display Group-Subfunktionen (Code D8H) 421 Miscellaneous Group (Code D9H) 421 Box Group (Code DAH) 423 Table End of Line Codes Group 429 Table End of Pages Codes Group (0DDH) 431 Enhanced Merge Functions (Code DEH) Rich Text Format (RTF Version 1.6) 437 Der Aufbau der RTF-Datei 438 Destination Control Words 440 Der Dokumentbereich 454 Verschiedene Kontrollwörter 512 Teil 3: Grafikformate 11 Das Adobe Illustrator File-Format (AI) 515 Die AI-Header-Comments Das Adobe Photoshop-Format (PSD) 533 Der Photoshop-Header 533 Der Mode Data-Block 534 Der Resource Data-Block 535 Der Bilddatenbereich AutoCAD Drawing Exchange Format (DXF) 537 Aufbau einer DXF-Datei 537 Der DXF-Header 548 DXF Table-Section 554 BLOCK-Abschnitt einer DXF-Datei 564 DXF Entities Section 566 AutoCAD Binary DXF 580 Das Drawing Exchange Binary-Format (DXB) 581 Inhalt 7

5 14 Das Autodesk Animator-Format (FLI) 583 Der FLI-Header 583 Die FLI-Frames 584 Das Animator CEL- und PIC-Format Das Autodesk 3D Studio-Format (FLC) 591 Der FLC-Header 591 Die FLC-Frames Das Audio/Video Interleaved-Format (AVI) 599 Die Resource Interchange File Format (RIFF)-Spezifikation 599 Der AVI-Header-CHUNK (hdrl) 601 Andere Daten-CHUNKs Windows Bitmap-Format (BMP) 611 Erweiterter Header in Windows 3.x 611 Erweiterter Header in Windows NT 614 Erweiterter BMP4-Header (Windows 95) 615 Der Datenbereich 616 Das Windows RLE-Format (RLE) OS/2 Bitmap-Format (BMP) 621 OS/2 Bitmap-Format (Version ) 621 OS/2 Bitmap-Format (Version 2.0) Das CAS Fax-Format (DCX) 631 Der DCX-Header Computer Graphic Metafile-Format (CGM) 633 Binäre CGM-Kodierung 633 Kodierung als ASCII-Text 639 Die Character-Kodierung mit ISO-Zeichen 642 Metafile-Anweisungen Das Dr. Halo-Format (PIC, CUT, PAL) Inhalt

6 22 Graphics Interchange Format (GIF) 661 Der GIF-Header 662 Die GIF-Blocks 662 Subblocks mit Raster-Daten GEM Image File-Format (IMG) 681 Der IMG-Kopfsatz 682 Speichern von IMG-Daten 685 Bildkomprimierung bei IMG-Dateien 686 Pixelkodierung 686 Das Solid Run-Format 687 Das Bit String-Format 687 Das Pattern Run-Format 688 Das Vertical Replication Count-Format GEM-Metafile-Format (GEM) 693 Der Aufbau des GEM-Metafile-Headers 693 Das Format der Metafile-Objekte 695 Generalized Drawing Primitives (GDP Opcode 0BH) 699 Erweiterungen in GEM/ Initial Graphics Exchange Language (IGES) 719 Die Start-Section 720 Die Global-Section 720 Die Directory-Entry-Section 722 Die Parameter Data-Section 724 Die Terminate-Section 724 Die Elemente einer IGES-Datei Interchange File Format (IFF) 733 Der IFF-Header 734 IFF-Blockstruktur (CHUNK) 736 Die CHUNKs eines ILBM-FORMs 738 Die CHUNKs eines 8SVX-FORMs 744 Die CHUNKs des AIFF-FORM 747 Inhalt 9

7 Die CHUNKs des SMUS-FORM 748 Die CHUNKs des FTXT-FORM 749 Allgemeine CHUNKs Das JPEG/JFIF-Format (JPG) 757 Die Marker einer JFIF-Datei 758 Das SPIFF-Format Das MAC-Paint-Format (MAC) 771 Der MAC-Header 772 Der MAC-Datenbereich Das MAC-Picture-Format (PICT) 777 Der PICT-Header 778 Der PICT-Datenbereich Micrografx-Formate (PIC, DRW, GRF) 789 Recordtypen in den Grafikdateien 792 Recordaufbau der Version Recordaufbau der Version Recordaufbau der Version Recordaufbau der Version Recordaufbau der Version WINDOWS 2.0 PAINT File-Format (MSP) 819 Der MSP-Header 819 Die Indextabelle 820 Der Datenbereich Die PBM-Formate (PBM, PGM, PPM) 823 Der PBM-Header 823 Der PGM-Header 823 Der PPM-Header 824 Bilddaten Inhalt

8 33 ZSoft Paintbrush File Format (PCX) 825 Der Aufbau des PCX-Headers 827 CGA-Farbpaletteninformationen 829 EGA/VGA-Palette mit 16 Farben 830 VGA-Palette mit 256 Farben 830 Die Kodierung der PCX-Daten 831 Das Format der PC Paintbrush-Bitmap-Zeichen 834 Das CAPTURE File-Format (SCR) Das PCPAINT/Pictor-Format (PIC) 837 Der PCPAINT/Pictor-Header 837 Der PIC-Datenbereich Das Portable Network Graphics-Format (PNG) 843 Der Aufbau der PNG-Datei 843 Kritische CHUNKs 845 Untergeordnete (ancillary) CHUNKs 847 Der Bilddatenbereich Das Apple QuickTime-Format (QTM) 855 Das Movie Directory-Atom 856 Das Movie Header-Atom 857 Das Track Directory-Atom Das SUN Rasterformat (RAS) 861 Der RAS-Header 861 Der Palettendatenbereich 863 Der RAS-Datenbereich Das TARGA-Format (TGA) 865 Der TARGA-Header 865 Struktur des Headers 867 Palettendaten 869 Inhalt 11

9 Der Bilddatenbereich 870 Erweiterungen des TARGA-Formats Tag Image File Format (TIFF 6.0) 877 Der TIFF-Header 877 Der Aufbau des Image File Directory (IFD) 878 Der Aufbau eines Tags 879 Beschreibung der Tag-Typen 881 TIFF-Komprimierungsverfahren Das Windows Metafile-Format (WMF) 925 Der Metafile-Header 925 Die Metafile-Records 926 Das Enhanced Metafile-Format (EMF) WordPerfect Graphic File Format (WPG) 951 WPG-Header 951 WPG-Records 951 Teil 4: Soundformate 42 Das Creative Music File-Format (CMF) 965 Der CMF-Header 965 Der Instrument-Block 967 Der Music-Block 969 Die Steuerbefehle Das Creative Voice-Format (VOC) 975 Der VOC-Header 975 Der VOC-Datenbereich Das AMIGA MOD-Format 981 Der MOD-Header 981 Der Noten-Block 982 Der Instrumentdatenbereich Inhalt

10 45 Das MIDI-File-Format (MID) 985 Der MIDI Header-CHUNK 985 Der Track-CHUNK 987 Die MIDI-Events 989 Die Steuerbefehle 993 Die MIDI-Betriebsartenbefehle 995 Local Control 995 All Notes off 995 Die MIDI-Programm-Befehle 996 Die MIDI-Timing-Befehle 997 Die MIDI-System-Common-Befehle 997 Die Meta-Events Das Windows WAV-Format 1005 Der WAV-Header 1005 Der FMT-CHUNK 1006 Der DATA-CHUNK 1006 Teil 5: Beschreibungssprachen 47Hewlett Packard Graphic Language (HP-GL/2) 1009 HP-GL/2-Gruppen 1010 Configuration and Status Group 1012 Vector Group 1014 Polygon Group 1017 Line and Fill Attributes Group 1019 Character Group 1021 Technical Graphics Extension 1024 Palette Extension 1027 Dual Context Extension 1028 Digitizing Extensions PostScript und Encapsulated PostScript (EPS) 1031 Die EPS-Strukturkonventionen 1034 PostScript-Anweisungen (Level 1) 1036 PostScript Level Inhalt 13

11 49 Das Portable Document Format (PDF) 1067 Hinweise zu PDF-Befehlen Standard Generalised Markup Language (SGML) 1071 Struktur einer SGML-Datei 1071 Struktur eines Dokuments Extended Markup Language (XML) 1081 XML-Dateistruktur 1081 XML-Elemente 1083 Hinweise zur Extended Backus-Naur Form (EBNF) Hypertext Markup Language (HTML) 1089 HTML-Varianten 1089 Die Grundstruktur einer HTML-Datei 1090 Sonderzeichen in HTML 1091 Gestaltung von Überschriften 1093 Horizontale Linien im Dokument 1096 Dokumente mit Aufzählungen gestalten 1097 Numerierungen in Dokumenten verwenden 1097 Grafiken in HTML-Dokumenten 1098 Hintergrundbilder und Hintergrundfarben 1099 Verweise in HTML-Dokumenten 1099 Tabellen in HTML-Dokumenten 1101 HTML-Referenz 1102 Index Inhalt

12 1 Lotus Format (WKS/WK1) Der Erfolg des Tabellenkalkulationsprogramms LOTUS führt dazu, daß eine riesige Anzahl von Dateien in diesem Format entstanden ist. Viele Anwendungsprogramme unterstützen zumindest den Import von Daten in diesem Format. In Abhängigkeit von der verwendeten LOTUS-Version (1.0, 1.A, 2.01, 2.2 oder 3.0) haben diese Dateien die Erweiterung WKS, WK1 oder WK3. Im vorliegenden Kapitel wird das WKS/WK1-Format (bis Version 2.01) vorgestellt. Tabellenkalkulation Der Aufbau der WKS/WK1-Dateien Sowohl LOTUS als auch die Tabellenkalkulation Symphony legen Daten und Kalkulationsformeln in Binärdateien ab. Texte aus den Rechenblättern werden dabei im ASCII-Format innerhalb der Binärdatei gespeichert. Die Dateien erhalten je nach verwendeter Programmversion die Erweiterung WKS oder WK1. Auch wenn sich einige Unterschiede zwischen den Dateien der LOTUS-Versionen ergeben, besitzen diese doch einen übereinstimmenden Satzaufbau. Alle Informationen werden satzweise in Records mit folgender Struktur gespeichert: <Recordtyp> <Record Länge> <Daten> Der Satzaufbau ist auch zwischen LOTUS und Symphony gleich und läßt sich über alle Versionen verfolgen. Die einzelnen Felder besitzen folgende Bedeutung: Das Feld Recordtyp ist zwei Bytes lang und enthält Informationen über den Recordtyp. Dieser bestimmt den Aufbau des nachfolgenden Datenfeldes. Bei Sätzen mit Daten wird dieser Recordtyp auch als Opcode für Rechenanweisungen oder zum Aufbau des Kalkulationsblatts interpretiert. Die beiden Begriffe (Recordtyp/Opcode) werden deshalb synonym benutzt. Beim Feld Recordtyp wird allerdings zuerst im niederwertigen Byte gespeichert; die Opcodes variieren mit den LOTUS-Versionen. Das Längenfeld umfaßt zwei Bytes und spezifiziert die Länge des nachfolgenden Datenfeldes in Byte. Dabei wird das LSB ebenfalls zuerst abgespeichert. Das Datenfeld besitzt eine variable Länge, die durch den jeweiligen Feldtyp spezifiziert wird. In diesem Feld finden sich Werte, Berechnungsformeln, Definitionen für den Aufbau des Kalkulationsblatts etc. Bei der Interpretation einer LOTUS- oder Symphony-Datei mit dieser Struktur lassen sich die einzelnen Sätze leicht extrahieren. Lediglich einzelne Opcodes, die jedoch alle aufwärtskompatibel sind, variieren zwischen den Versionen. An dieser Stelle noch eine Anmerkung: In Lotus werden Zeilen und Spalten aus Benutzersicht mit Buchstaben und Nummern versehen. Intern benutzen LOTUS und Symphony Zeilen- bzw. Spaltennummern mit 16-Bit-Breite, wodurch sich jede Feldposition eindeutig durch zwei Zahlen identifizieren läßt. Innerhalb der Datei wird diese Numerierung ebenfalls verwendet. Lotus Format (WKS/WK1) 17

13 Abbildung 1.1 Spalten- und Zeilennumerierung Recordtypen in Lotus (Versionen 1.1 bis 2.01) Nachfolgend werden die in den WKS-Dateien vorkommenden Satzarten (Opcodes), die sowohl von LOTUS als auch von Symphony benutzt werden, mit ihren Datenstrukturen vorgestellt. Jeder Opcode umfaßt zwei Byte, wobei das LSB (niedrigstwertiges Byte) zuerst gespeichert wird. Spätere Programmversionen enthalten grundsätzlich die gleichen Opcodes, wurden jedoch um einige neu hinzugefügte Satzarten erweitert. BOF (Opcode 0000H) Dieser Feldtyp markiert den Beginn einer gültigen WKS-/WK1-Datei. Der Record besitzt folgenden Aufbau: 00H 2 Opcode BOF = 0000H 02H 2 Länge = H 2 Versionsnummer Dateiformat 0404H WKS-Format in Version 1.A 0405H Symphony Datei H Datei im WK1-Format ab Version 2.01 und Symphony 1.1 Tabelle 1.1 LOTUS-WKS-Recordstruktur (Opcode 0000H) Das Datenfeld faßt zwei Bytes, in denen der Versionscode des Dateiformats abgelegt ist. Neuere Versionen von LOTUS und Symphony setzen diese Numerierung fort. EOF (Opcode 0001H) Dieser Record bildet den Abschluß einer WKS- oder WK1-Datei. Der Satz besitzt folgenden Aufbau: 00H 2 Opcode EOF = 0001H 02H 2 Länge = 0000 Tabelle 1.2 LOTUS-WKS-Recordstruktur (Opcode 0001H) Der Satz ist lediglich 4 Bytes lang, das Datenfeld bleibt unbesetzt. 18 Lotus Format (WKS/WK1)

14 CALC_MODE (Opcode 0002H) In LOTUS kann der Anwender festlegen, ob eine Neuberechnung der Ergebnisse automatisch nach jeder Eingabe (Standardeinstellung) oder erst auf manuelle Anforderung hin stattfindet. Der Berechnungsmodus wird in einem eigenen Record in der Datendatei mitgespeichert. Der Satz besitzt folgenden Aufbau: 00H 2 Opcode CALC_MODE = 0002H 02H 2 Länge = H 1 Berechnungsmodus 00 = manuelle Neuberechnung FF = automatische Neuberechnung Tabellenkalkulation Tabelle 1.3 LOTUS-WKS-Recordstruktur (Opcode 0002H) Standardmäßig enthält das Datenbyte den Wert FFH für eine automatische Neuberechnung (Recalculation) nach jeder Eingabe. CALC_ORDER (Opcode 0003H) Bei jeder Berechnung der Ergebnisse läßt sich festlegen, in welcher Reihenfolge die Formeln in der Tabelle bearbeitet werden. Diese Einstellung wird ebenfalls in einem Satz mit folgendem Aufbau gesichert: 00H 2 Opcode CALC_ORDER Opcode = 0003H 02H 2 Länge = H 1 Berechnungsmodus 00 = natürliche Reihenfolge 01 = spaltenweise Berechnung FF = zeilenweise Berechnung Tabelle 1.4 LOTUS-WKS-Recordstruktur (Opcode 0003H) Bei der spaltenweisen Berechnung (Code 01) werden erst die Formeln der betreffenden Spalte abgearbeitet. Anschließend beginnt LOTUS mit der Berechnung der Formeln der folgenden Spalte. WINDOW_SPLIT (Opcode 0004H) LOTUS erlaubt die Aufteilung des Bildschirms in zwei Hälften (horizontal/vertikal). In Abhängigkeit vom gesetzten Modus wird ein Kennbyte in einem Record mit folgender Struktur abgespeichert: Recordtypen in Lotus (Versionen 1.1 bis 2.01) 19

15 00H 2 Opcode Window_Split = 0004H 02H 2 Länge = H 1 Split Code 00H = kein Split 01H = vertikaler Split FFH = horizontaler Split Tabelle 1.5 LOTUS-WKS-Recordstruktur (Opcode 0004H) Standardmäßig wird der Wert 00H im Datenfeld gespeichert. Nur bei aufgeteiltem Bildschirm (Split) finden sich die Codes 01H oder FFH im Datenbyte. CURSOR_SYNC (Opcode 0005H) Dieser Feldtyp spezifiziert, ob die Synchronisation der Cursorbewegungen innerhalb eines Fensters ein- oder ausgeschaltet ist. Der Record besitzt folgenden Aufbau: 00H 2 Opcode CURSOR_SYNC = 0005H 02H 2 Länge = H 1 Code 00H = Fenster nicht synchronisiert FFH = Fenster synchronisiert Tabelle 1.6 LOTUS-WKS-Recordstruktur (Opcode 0005H) Das Datenfeld umfaßt ein Byte mit dem Code. SAVE_RANGE (Opcode 0006H) Mit dem Satz wird in LOTUS der Bereich (RANGE) der in der Datei zu speichernden Zellen spezifiziert, wobei in der Regel das komplette Rechenblatt gesichert wird. Es gilt folgender Aufbau: 00H 2 Opcode SAVE_RANGE = 0006H 02H 2 Länge = 0008H 04H 2 Start Spalte (Column) 06H 2 Start Zeile (Row) 08H 2 Ende Spalte (Column) 0AH 2 Ende Zeile (Row) Tabelle 1.7 LOTUS-WKS-Recordstruktur (Opcode 0006H) 20 Lotus Format (WKS/WK1)

16 Im Datenfeld werden die obere linke Ecke (Zeile/Spalte) und die untere rechte Ecke abgelegt. Falls die Datei durch das File Save-Kommando angelegt wurde, finden sich alle Felder des Rechenblatts in der Datei. Mit File Xtract werden nur die Zellen des spezifizierten Ausschnittes abgespeichert. Dann finden sich die Koordinaten des Ausschnittes im Datenfeld. Zu beachten ist, daß LOTUS die Spalten- und Zeilenadressen als 16-Bit- Nummern ablegt (das LSB wird dabei zuerst gespeichert). Beim Abspeichern der Zellen werden leere Felder am Ende einer Spalte oder Zeile nicht berücksichtigt. Sind keine Daten in dem mit Range bezeichneten Bereich vorhanden, setzt LOTUS im Datenfeld den Wert der Startspalte auf 1. Der Satztyp 06H findet sich in der Regel direkt nach dem BOF-Record. Dies sollte auch beachtet werden, falls WKS- oder WK1-Dateien durch Fremdprogramme angelegt werden. Tabellenkalkulation WINDOW1 (Opcode 0007H) ;In LOTUS lassen sich zwei Fenster definieren: Unter dem Opcode 07H wird die Einstellung des ersten Fensters (WINDOW1) abgespeichert. Es gilt folgender Satzaufbau: 00H 2 Opcode WINDOW1 = 0007H 02H 2 Länge 001FH bei WKS-Dateien 0020H bei WK1-Dateien 04H 2 Spalte aktuelle Cursorposition 06H 2 Zeile aktuelle Cursorposition 08H 1 Zellformat (Byte) 09H 1 unbelegt (00) 0AH 2 Spaltenbreite 0CH 2 Zahl der Spalten auf dem Bildschirm 0EH 2 Zahl der Zeilen auf dem Bildschirm 10H 2 linke Bildschirmspalte 12H 2 oberste Zeilennummer 14H 2 Zahl der Titelspalten 16H 2 Zahl der Titelzeilen 18H 2 linke Spalte, an der der Titel beginnt 1AH 2 oberste Zeile, an der der Titel beginnt 1CH 2 Breite der Randspalte 1EH 2 Breite der Randzeile 20H 2 Breite des Fensters (WINDOW) 22H 2 unbelegt (00 00) Tabelle 1.8 LOTUS-WKS-Recordstruktur (Opcode 0007H) Recordtypen in Lotus (Versionen 1.1 bis 2.01) 21

17 Die Angaben in der Spalte Offset erfolgen in der Hexadezimalnotation. Alle 16-Bit-Werte enthalten das LSB im ersten Byte. Die Recordlänge variiert zwischen den einzelnen LOTUS-Versionen: LOTUS 1.A legt WKS-Dateien mit einem WINDOW1-Datenbereich von 31 Byte (1FH) an, während die Satzlänge der WK1-WINDOW1-Records ab LOTUS Byte (20H) beträgt. Meines Wissens sind jedoch in allen Versionen die Bytes ab Offset 22 unbelegt und auf 00 gesetzt. In den beiden ersten Worten speichert LOTUS die Informationen über die aktuelle Cursorposition im Arbeitsblatt. Ab Offset 08H findet sich ein Byte mit der Kodierung des Zellformats im Arbeitsblatt. Dieses Byte besitzt folgenden Aufbau: Abbildung 1.2 Kodierung LOTUS-Zellformat Das oberste Bit gibt an, ob die Zellen innerhalb des Fensters für Schreibzugriffe gesperrt (protected) sind. Dabei gilt folgende Kodierung: Bit 7 Funktion 1 1 protected 0 0 unprotected Tabelle 1.9 Kodierung der Formate in LOTUS In den Bits 4 bis 6 wird eine dreistellige Binärzahl mit dem Formattyp der Wertedarstellung geführt. Die Nomenklatur dazu sieht so aus: Bit 654 Format 000 Festkommaformat (fixed) 001 Exponentdarstellung (scientific notation) 010 Währungsdarstellung (currency) 011 Prozent 100 Komma 101 Frei 110 Frei 111 Spezialformat Tabelle 1.10 Kodierung der Formate in LOTUS Für die Formattypen 0 bis 6 spezifizieren die restlichen Bits 0 bis 3 die Zahl der Dezimalstellen (zwischen 0 und 15). Der Formattyp 7 repräsentiert ein spezielles Format, das mit den Bits 0 bis 3 noch näher spezifiziert wird. 22 Lotus Format (WKS/WK1)

18 Bit 3210 Format / 0001 generelles Format 0010 Datumsformat: Tag, Monat, Jahr 0011 Datumsformat: Tag, Monat 0100 Datumsformat: Monat, Jahr 0101 Textformate 0110 Unbelegt 0111 Unbelegt 1000 Unbelegt 1001 Unbelegt 1010 Unbelegt 1011 Unbelegt 1100 Unbelegt 1101 Unbelegt 1110 Unbelegt 1111 Standarddarstellung Tabellenkalkulation Tabelle 1.11 Kodierung des Spezialformates in LOTUS In den restlichen Wörtern finden sich weitere Informationen über das Bildschirmfenster wie beispielsweise die Spaltenbreite, die Spaltenzahl des Bildschirms etc. COLUMN_WIDTH_1 (Opcode 0008H) Mit diesem Satz wird in LOTUS die Spaltenbreite in Fenster 1 spezifiziert. Es gilt folgender Satzaufbau: 00H 2 Opcode COLUMN_WIDTH_1 = 0008H 02H 2 Länge = 0003H 04H 2 Spaltennummer (16 Bit) 06H 1 Breite der Spalte Tabelle 1.12 LOTUS-WKS-Recordstruktur (Opcode 0008H) Im Datensatz für die WINDOW1-Definition gibt es bereits einen Eintrag für die Spaltenbreite. Dieser Wert bezieht sich jedoch auf alle Spalten des Rechenblatts, während sich mit dem Record 08H die Breiten verschiedener Spalten angeben lassen. Im ersten Wort steht dabei die betreffende Spaltennummer (LSB zuerst!). Das folgende Byte gibt die Breite der Spalte in Zeichen an. Recordtypen in Lotus (Versionen 1.1 bis 2.01) 23

19 Der Satztyp wird lediglich dann angelegt, wenn einzelne Spalten von der globalen Definition abweichen. WINDOW2 (Opcode 0009H) Der Record sichert in LOTUS die Einstellung des zweiten Fensters. Es gilt der gleiche Satzaufbau wie bei WINDOW1 (Opcode 07H). COLUMN_WIDTH_2 (Opcode 000AH) Falls ein WINDOW2 gesichert wurde, besteht die Möglichkeit, die Spaltenbreite individuell vorzugeben. Für das WINDOW2 werden diese Definitionen im Satztyp COLUMN_ WIDTH_2 (Opcode 0AH) gespeichert. Er besitzt den gleichen Aufbau wie der Satztyp COLUMN_WIDTH_1 (Opcode 08H). NAME (Opcode 000BH) Mit dem Satz läßt sich der Name eines Bereichs (RANGE) in LOTUS speichern. Es gilt folgende Struktur: 00H 2 Opcode NAME = 000BH 02H 2 Länge = 0018H (24 Bytes) 04H 16 ASCIIZ-String mit dem Namen 14H 2 Startspalte Range 16H 2 Startzeile Range 18H 2 Endspalte Range 1AH 2 Endzeile Range Tabelle 1.13 LOTUS-WKS-Recordstruktur (Opcode 000BH) Jedem markierten Bereich (RANGE) läßt sich in LOTUS ein Name zuweisen. Der Name darf bis zu 16 Zeichen lang sein und wird ab dem ersten Byte als ASCIIZ-String (Text mit 00H abgeschlossen) gesichert. Daran schließen sich die Start- und Endekoordinaten des Bereichs an. Für jeden markierten Bereich muß ein eigener Satz gespeichert werden. BLANK (Opcode 000CH) Normalerweise speichert LOTUS leere Zellen nicht mit ab, so daß geschützte oder formatierte Leerzellen beim Speichern eigentlich verlorengehen. Die Satzart 0CH sichert auch solche Zellen und hat folgende Struktur: 00H 2 Opcode BLANK = 000CH 02H 2 Länge = 0005H Tabelle 1.14 LOTUS-WKS-Recordstruktur (Opcode 000CH) 24 Lotus Format (WKS/WK1)

20 04H 1 Formatbyte 05H 2 Spaltennummer 07H 2 Zeilennummer Tabelle 1.14 LOTUS-WKS-Recordstruktur (Opcode 000CH) Im ersten Datenbyte speichert LOTUS die Kodierung für die Formatierung (vorgestellt in Tabelle 1.9/1.10 beim WINDOW1-Record). Anschließend folgen zwei Worte mit den Koordinaten der Zelle. Tabellenkalkulation INTEGER (Opcode 000DH) Direkt eingegebene Ganzzahlen (Integer) werden aus dem Rechenblatt in die Datei übernommen. Der Record besitzt folgende Struktur: 00H 2 Opcode INTEGER = 000DH 02H 2 Länge = 0007H 04H 1 Formatbyte 05H 2 Spaltennummer 07H 2 Zeilennummer 09H 2 Integerwert Tabelle 1.15 LOTUS-WKS-Recordstruktur (Opcode 000DH) Der Satz besitzt insgesamt 7 Datenbytes, wobei im ersten Byte das Zahlenformat abgelegt wird. Die Kodierung ist in Tabelle 1.9/1.10 (siehe WINDOW1) aufgeführt. In den folgenden Wörtern steht die Position der Zelle mit dem Integerwert. Anschließend folgt ein 16- Bit-Wort, das dann den Integerwert enthält. Das oberste Bit gibt an, ob der Wert positiv (Bit = 0) oder negativ (Bit = 1) ist. In einer Integerzahl läßt sich somit ein Wertebereich zwischen und abbilden. NUMBER (Opcode 000EH) Mit diesem Recordtyp sichert LOTUS Fließkommazahlen. Der Record besitzt folgende Struktur: 00H 2 Opcode NUMBER = 000EH 02H 2 Länge = 000DH (13 Datenbytes) 04H 1 Formatbyte 05H 2 Spaltennummer Tabelle 1.16 LOTUS-WKS-Recordstruktur (Opcode 000EH) Recordtypen in Lotus (Versionen 1.1 bis 2.01) 25