<\/p>\n
Unter Textverarbeitungssystemen sind Erwägungen zu den verwendeten Schriften selbstverständlich. Hier bestimmen neben der Lesbarkeit auch Gesamtlayout und Schriftbild den Einsatz verschiedener Schriftarten. Welche überlegungen für die Anforderungen an Schriften unter Access-Formularen und -Berichten anzustellen sind, soll in diesem Beitrag diskutiert werden.<\/b><\/p>\n
Beispieldatenbank<\/b><\/p>\n
Die Beispiele dieses Artikels finden Sie in der Datenbank 1409_Fonts.mdb<\/b>.<\/p>\n
Was unterscheidet Schriften<\/b><\/p>\n
Holen wir uns zunächst ins Bewusstsein, durch welche Parameter eine Schrift im Groben charakterisiert ist.<\/p>\n
Technisch gesehen gibt es einmal die Raster-Fonts und dann die Vektor-Fonts. Raster-Fonts sind Schriftdateien, in denen die einzelnen Zeichen als Bitmaps gespeichert sind, wobei meist für verschiedene Größen auch verschiedene Bitmaps eingebettet sind. Die grafische Skalierbarkeit dieser Fonts ist daher eingeschränkt und das Schriftbild bescheiden. Zum Einsatz kommen diese Fonts nur noch selten.<\/p>\n
In Vektor-Fonts wird jedes Zeichen durch einen Satz von Liniensegmenten definiert, deren Stützpunkte jeweils die Hülle ergeben, innerhalb derer ausgefüllt wird. Sie lassen sich beliebig verlustlos skalieren. Die beiden Hauptvertreter sind TrueType <\/b>(.ttf<\/b>) und OpenType<\/b>-Schriften (.otf<\/b>).<\/p>\n
Stilistisch gesehen gibt es unterschiedliche Kategorien. Die eine ist die Zeichenbreite. Im Allgemeinen hat jedes Zeichen eine eigene Breite – ein i<\/b> ist nun mal schmaler als ein W<\/b>. Schriften, die dem gerecht werden, sind Proportionalschriften.<\/p>\n
Für spezielle Zwecke jedoch werden auch nichtproportionale Schriften benötigt, bei denen jedes Zeichen dieselbe Breite aufweist, erkennbar oft schon am Namen der Schrift, der häufig ein Mono<\/b> enthält, abgeleitet von Mono Space<\/b>.<\/p>\n
Rein optisch ist das weniger schön, aber immer dann sinnvoll, wenn untereinanderstehende Zeilen Bezug zueinander haben. Etwa in Rechnungen, wo Zahlen untereinander addiert werden. Oder auch der übersichtlichkeit halber in Programmcode, wie in den Code-Modulen von VBA. An dieser Stelle, da es zum Thema passt, ein kleiner Einschub:<\/p>\n
Die Schriftart des VBA-Editors können Sie in dessen Optionen-Dialog einstellen – s. Bild 1. Testen Sie einmal, wie der Programmcode je nach eingestellter Schriftart wirkt und welche Varianten die Lesbarkeit fördern. Es stellt sich heraus, dass jenen mit fester Zeichenbreite meist der Vorzug zu geben ist. Es ist common sense für Code-Editoren, solche Schriftarten mit fixed pitch <\/b>zu verwenden. Tatsächlich ist das Kombinationsfeld für die Schriftarten im Optionen-Dialog auch gefiltert; nicht alle installierten Schriftarten erscheinen dort.<\/p>\n
![\"Auswahl](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_001.png\")
<\/p>\n
Bild 1: Auswahl der Schriftart für den VBA-Code im Optionen-Dialog<\/span><\/b><\/p>\n Allerdings erschließt sich uns nicht, nach welchen Kriterien die Schriften hier gefiltert sind. Es sind keineswegs nur nichtproportionale Schriften aufgeführt. Zu allem überfluss stürzt VBA, und damit Access, übrigens auch noch bei der Auswahl einiger Schriftarten ab – ein Bug, der schon seit Urzeiten von VBA mitgeschleppt wird. Sollte dies passiert sein, so bleibt Ihnen nur die Korrektur über die Registry, weil VBA jedes Mal erneut abstürzt, sobald es geöffnet wird. An den Optionen-Dialog kommen Sie somit nicht mehr heran. ändern Sie dann in der Registry diesen Zweig<\/p>\n und überschreiben Sie den Wert für FontFace<\/b> mit einer Schriftart wie Courier New<\/b>.<\/p>\n Zurück zu den Schriftartkategorien. Neben der Breite der Zeichen ist deren Gestalt relevant. So gibt es die zwei Haupttypen Serifen- und serifenlose Schriften. Serifen sind die Füßchen am Ende der Balken. Sie haben den Sinn, bei Textblöcken optisch virtuelle Leitlinien für das Auge zu bilden und damit den Lesefluss zu verbessern.<\/p>\n In Printmedien sind diese Schriften, deren Hauptvertreter die Times darstellt, nach wie vor weit verbreitet.<\/p>\n Die Füßchen haben jedoch im Auslauf so kleine Abmessungen, dass sie auf Monitoren auch bei den heute gängigen Auflösungen und Pixelgrößen nicht hinreichend dargestellt werden können. Entweder werden sie krakelig oder durch das Antialiasing verwaschen, was störend wirkt. Aus diesem Grund werden hier für normalen Text eher serifenlose Schriften bevorzugt. Daher gilt dies auch für das vorliegende Dokument: Access im Unternehmen<\/b> verwendet die serifenlose Helvetica<\/b>, die unter anderem E-Books einfach lesbarer macht.<\/p>\n Oder fänden Sie diese Zeilen hier etwa besser zu lesen, wenn die Schriftart Times New Roman <\/b>angewandt würde<\/p>\n Es bleibt festzuhalten, dass am Monitor die serifenlosen Schriften günstiger sind, weshalb Microsoft diese unter Access auch als Standard festgelegt hat. Einst war es MS Sans Serif<\/b>, dann Tahoma<\/b>, Arial<\/b>, und seit Office 2007 sind Calibri <\/b>und Segoe UI <\/b>das Maß der Dinge. <\/p>\n Kaum der Erwähnung wert ist die Tatsache, dass auch Schriftarten wie Handwriting<\/b>, barocke Stile oder andere verschnörkelte Typen auf dem Monitor in einer nüchternen Umgebung wie Access nichts zu suchen haben. <\/p>\n Mit dem Problem der ungenügenden Auflösung hat auch eine andere Kategorie zu kämpfen: die Lage der Schrift. In Printmedien werden bestimmte Ausdrücke etwa dadurch hervorgehoben, dass sie kursiv gedruckt sind. Auf Monitoren führt die Steillage von Balken jedoch zu Sprüngen der Pixel, also einer Treppe statt einer Linie, weshalb Antialiasing notwendig wird.<\/p>\n Dieses wiederum ist nur ein Notbehelf, weil die Schrift dann verwaschener wird, da die Interpolation zu Pixeln führt, die grau statt schwarz sind. Je kleiner die Schrift, desto mehr tritt dieser Effekt in Erscheinung.<\/p>\n Aus diesem Grund verwendet auch Access im Unternehmen<\/b> keine kursiven Zeichen, sondern nimmt zur Hervorhebung ausschließlich fett gedruckte Worte. Auch Sie sollten den Einsatz von kursiver Schrift unter Access genau abwägen. Brauchen Sie sie wirklich<\/p>\n Soweit zu den Grundkategorien von Schriften. Bliebe noch das eigentliche Design. Die Kunst des Schriftendesigners ist darin begründet, diverse Anforderungen unter einen Hut zu bringen. Die Schrift soll konsistent wirken und den Eindruck einer gleichmäßigen Helligkeitsverteilung über einem Textblock hervorrufen. Auch kleine Zeichen sollen deutlich und schnell erkennbar sein.<\/p>\n Das Auge soll schnell entlang der Zeilen geführt werden und beim Springen im Text Passagen wiederfinden. Hierfür gibt es kein Erfolgsrezept, denn diese Erfordernisse sind je nach Textinhalt und Bestimmungszweck unterschiedlich zu gewichten.<\/p>\n Es ist eben etwas Anderes, ob die Schrift für einen kurzen Text eines Bezeichnungsfelds herhalten soll, oder für einen Erläuterungsblock, für eine Tabelle, oder für den Ausdruck über einen Bericht. Bevor wir uns damit im Folgenden beschäftigen, kurz noch einige Definitionen zur Gestalt der Schriftzeichen. Betrachten Sie hierzu Bild 2.<\/p>\n Bild 2: Einzelne Dimensionsteile einer Schriftart<\/span><\/b><\/p>\n Der Abstand zwischen Klein- und Großbuchstaben sind die Oberlängen. Der größte Kleinbuchstabe bildet die Mittellänge. Darunter finden sich für die Zeichen g<\/b>, j<\/b>, y<\/b> und so weiter die Unterlängen. Ganz unten schließt der sogenannte Durchschuss die Zeichen ab. Das ist im Prinzip der Abstand zwischen den Zeilen. Unter Word etwa spielt dieser in der Schriftdatei definierte Durchschuss keine so große Rolle, weil Sie da den Zeilenabstand gesondert für Absätze einstellen können, unter Access haben Sie darauf jedoch keinen Einfluss. Und hier liegt der Hund begraben! Leider sind 10 Punkt in der einen Schriftart nicht dasselbe wie in einer anderen.<\/p>\n Zwar ist eigentlich genau definiert, was die Punktgröße einer Schrift ausmacht. Es ist die Summe von Ober-, Mittel- und Unterlänge ohne Durchschuss. Demnach müsste jede Schriftart der Größe 10 Punkt exakt die gleiche Höhe haben.<\/p>\n In der Realität wird davon jedoch abgewichen und für die Punktgröße häufig auch ein Teil des Durchschusses abgezwackt. In der Folge variiert die reelle Höhe je nach Schriftart locker um den Faktor 3. Sie können sich also bei der Schrifthöhe nicht allein auf die Punktgröße verlassen. <\/p>\n Ein Punkt ist übrigens definiert durch das 72tel eines Inchs und ist damit etwa 0,35 mm groß. Ein 10pt-Font müsste also Zeichen von maximal 3,5 mm Höhe darstellen. Geht man von den gängigen Pixelabmessungen heutiger Monitore aus, muss demnach so ein Zeichen durch etwa 13-14 Pixel gerendert werden. Daran wird deutlich, dass für Serifen nicht ausreichend Spielraum besteht.<\/p>\n Schriften in Access-Berichten<\/b><\/p>\n Es hängt vom Zweck eines Access-Berichts ab, welche Schriften hier zum Einsatz kommen können. Soll der Bericht nur am Bildschirm angezeigt werden, so gilt für die Schriftarten weitgehend das Gleiche, wie für Formulare. Serifenlose Schriften sind zu bevorzugen. Die Lesbarkeit steht an erster Stelle.<\/p>\n Soll der Bericht auch, oder in erster Linie, gedruckt werden, so kommen auch Serifenschriften infrage. Dann können Sie dieselben überlegungen anstellen, wie für ein Word-Dokument. <\/p>\n Allerdings hängt es maßgeblich vom Inhalt des Berichts ab, welche Schriftart zum Einsatz kommt. Geht es um eine Tabellendarstellung oder gegliederte Ausgabe von Daten, so ist ein gleichmäßiges Schriftbild bei komprimierter Schriftgröße günstig, was gleichzeitig die Verwendung mehrerer Schriftarten im Dokument infrage stellt. Letzteres ist jedoch ohne Weiteres statthaft, wenn der Bericht der Ausgabe von Rechnungen dient, wobei man sich gemeinhin an die Vorlagen anlehnt, die auch unter Word für ein Geschäftsschreiben verwendet werden. <\/p>\n <\/p>\n Schriften in Formularen<\/b><\/p>\n Für den Einsatz von Schriftarten in Formularen gelten andere Erfordernisse. Zu unterscheiden wäre dabei zunächst zwischen normaler Formularansicht und Datenblattansicht. <\/p>\n Schriften für die Datenblattansicht<\/b><\/p>\n ähnlich, wie unter Excel, stellt sich bei tabellarischem Layout meist die Frage, wie sich Scrollen möglichst vermeiden lässt und viele Spalten oder Zeilen auf dem Monitor platziert werden können, ohne dass der Anwender zur Lupe greifen muss oder sich nach der Arbeit zur Teilnahme an einer Rückenschule genötigt sieht. Also ist eine möglichst kleine Schriftgröße im Verein mit optimaler Lesbarkeit gesucht. Da ein Datenblatt unter Access für alle Zellen nur eine Schrift vorsieht, braucht man sich um Konsistenz der Schrift bei verschiedenen Größen und Wichtungen nicht zu kümmern. Von Inhalt und Anzahl der Spalten hängt es ab, ob eine geringe Zeilenhöhe im Fokus steht oder eine Schriftart mit komprimierter Laufweite.<\/p>\n Nehmen Sie etwa die Tabelle aus Bild 3 auf der folgenden Seite. Die horizontale Ausdehnung des Datenblatts ist gering, da es nur vier Spalten aufweist. Folglich liegt das Augenmerk weniger auf Schriftarten, die eine geringe Laufweite haben, also horizontal komprimiert sind, als vielmehr darauf, möglichst viele Zeilen auf den Bildschirm zu bringen, um lästiges Scrollen zu vermeiden. Als Schriftarten kommen solche infrage, die eine geringe Höhe, einen kleinen Durchschuss aufweisen und dennoch gut lesbar sind.<\/p>\n Bild 3: Datenblattformular mit vertikaler Ausdehnung<\/span><\/b><\/p>\n Anders der Fall im Formular frmFonts <\/b>der Beispieldatenbank (s. Bild 4). Das eingebettete Datenblatt hat dort zahlreiche Spalten und somit vertikale Ausdehnung. Das horizontale Scrollen wird zwar unvermeidlich, sollte aber minimiert werden. Also benutzen wir hier eine Schrift, die möglichst klein ist, dennoch gut lesbar, aber deren Höhe weniger relevant ist als die Laufweite. Horizontal sollten möglichst viele Zeichen in die Spalten passen. Welche Schriftarten das sind, finden wir später noch heraus, wenn es um die Routinen der Beispieldatenbank geht.<\/p>\n Bild 4: Unterdatenblatt im Formular mit horizontaler Ausdehnung<\/span><\/b><\/p>\n Schriften für Eingabeformulare<\/b><\/p>\n Eingabemasken bestehen für gewöhnlich aus einem Mix von Bezeichnungsfeldern, Textfeldern und eventuell Listenfeldern. Für jedes dieser Elemente gelten andere Anforderungen. Während man für Listenfelder dieselben überlegungen wie für Datenblätter anstellen kann, möchte man Labels eher unscheinbar wirken lassen und wenig Platz für sie vergeuden.<\/p>\n Auf den Eingabefeldern, also Textboxen und Comboboxen, liegt der Fokus. Sie sollen deutlich hervorstechen. Natürlich gibt es neben der Schriftart auch noch weitere Gestaltungsmöglichkeiten, wie Schriftfarben, Hintergrundfarben und Rahmen der Steuerelemente zur ansprechenden Formatierung. Dennoch möchte man auch Textfelder so gestalten, dass möglichst viel Text in deren Eingaberechteck unterzubringen ist. Also ist auch hier die Laufweite der Schrift von Belang.<\/p>\n Grundsätzlich ist dabei anzuraten, nur eine Schriftart für das ganze Formular zu verwenden und auch die Schriftgrößen nicht zu variieren. Ausnahmen wären überschriften und Fußzeilen. Ansonsten können Hervorhebungen durch Fettdruck erfolgen. Das Ganze ist im Interesse eines ruhigen Gesamteindrucks der Benutzeroberfläche.<\/p>\n Schriftgröße<\/b><\/p>\n Die Schriftgröße ist wahrscheinlich ein Punkt, über den sich streiten lässt. über lange Zeit war von Microsoft aus 8pt-Schrift als Standard für Formulare voreingestellt. Ab Access 2007 war es plötzlich die 11-Punkt-Schrift.<\/p>\n In Printmedien war lange Zeit 10,5 als Standard auszumachen. Inzwischen scheint die Lesbarkeit nicht mehr oberste Priorität zu haben und man sieht sich, beeinflusst von vermeintlich () modernem Design, häufig auch mal mit einer Schriftgröße von 7pt konfrontiert – die Lesebrille hat man ja ab dem 35ten Geburtstag schließlich immer im Gepäck…<\/p>\n Tatsächlich gibt es Ergonomierichtlinien, die etwa für Software-Ausschreibungen auf EU-Ebene gelten, die kleinere Schriftgrößen als 9pt für die Benutzeroberfläche ausschließen. Das gilt dann auch für Datenblattansichten!<\/p>\n Wir empfehlen Ihnen, sich an diesen Maßstab zu halten. Andererseits scheinen die 11pt-Schriften von Access 2007 und neuer etwas übertrieben. Sie werden der Realität komplexer Formulare nicht gerecht. Zwar wird die arbeitende Belegschaft vor den Bildschirmen immer älter und die Sehkraft immer schlechter, aber solch große Schriften ziehen nun mal ein Oberflächenlayout nach sich, das die Produktivität dann seinerseits einschränkt.<\/p>\n Schwarz auf Weiß<\/b><\/p>\n Was für Printmedien gilt, sieht auf dem Bildschirm anders aus. Schwarz auf Weiß war lange selbstverständlich. Inzwischen stellt Microsoft für die Schriftfarben etwas anderes als Stilvorgabe ein, nämlich ein dunkles Grau. Und das mit gutem Grund. Wie bereits erwähnt kommt man für eine gute Schriftdarstellung um ein Antialiasing beim Rendern auf dem Bildschirm nicht herum. Bei schwarzer Schrift vor weißem Hintergrund entstehen so viel Grautöne, die die Zeichen etwas verschmieren lassen.<\/p>\n Dieser Effekt wird geringer, wenn von vornherein statt Schwarz ein Grau verwendet wird. Allerdings leidet der Kontrast so auch, weswegen ein Farbwert von &H202020 <\/b>wohl ausreicht.<\/p>\n Ist der Hintergrund selbst grau, dann kann selbstverständlich auch eine ganz schwarze Schrift eingesetzt werden – auf die Differenz kommt es an!<\/p>\n Fonts im überblick<\/b><\/p>\n Nach den doch recht theoretischen Ausführungen der letzten Absätze soll anhand der Beispieldatenbank zum Beitrag Antwort auf diese Fragen gegeben werden:<\/p>\n Welche Schriftarten sind geeignet Wie ermittle ich die Eigenschaften der Schriftarten Welche Schriften habe ich installiert Hat Microsoft Recht<\/p>\n Font-Liste auslesen<\/b><\/p>\n öffnen Sie das VBA-Modul mdlFontHeight <\/b>der Beispieldatenbank. Es enthält eine Menge API-Aufrufe, auf deren Funktionsweise nicht im Detail eingegangen werden soll. Ziel ist es, die Fonts Ihres Systems aufzulisten und diese Liste in eine Tabelle tblFontExtents <\/b>zu speichern. Neben den Namen der Schriften sollen auch einige Eigenschaften ausgelesen werden. Starten Sie die Prozedur EnumFonts <\/b>durch einen Aufruf im VBA-Direktfenster. Der Ablauf ist im Prinzip folgender:<\/p>\n EnumFontFamilies <\/b>ist die geeignete API-Funktion, die alle installierten Schriften durchläuft. Sie springt dabei für jede Schrift die Prozedur EnumFontFamProc<\/b> an und übergibt ihr deren Eigenschaften in API-Strukturen. In dieser werden die Werte über ein zuvor geöffnetes Recordset in die erwähnte Tabelle übertragen. Das sind Angaben zu Name der Schrift, Größe, Breite, Höhe der Zeichen und einige mehr. Der Clou ist die Funktion zum Bestimmen der Ausdehnung eines Beispieltextes, die aus Access selbst stammt:<\/p>\n Die versteckte Objektklasse Wizhook <\/b>nämlich enthält eine für diesen Zweck nützliche Funktion TwipsFromFont<\/b>, der als Parameter neben der Schriftart nur der Teststring zu übergeben ist. Heraus kommt die Breite des gerenderten Textes in der Maßeinheit Twips<\/b>. Dieses Ergebnis wird ebenfalls in der Tabelle gespeichert, damit später für verschiedene Schriftarten und -größen Vergleiche angestellt werden können. Für jede Schrift wird übrigens in einer Schleife dieser Wert erneut berechnet, indem als Größe 7pt bis 16pt übergeben wird. Pro Schriftart findet man also in der Tabelle letztlich 20 Datensätze: zehn Größen und die jeweils in Normal- und Fettdruck.<\/p>\n Deshalb braucht die Routine auch einige Zeit, wenn Sie zahlreiche Schriften auf Ihrem Rechner installiert haben.<\/p>\n Font-Beispiele ausgeben<\/b><\/p>\n Die Tabelle mit den Font-Eigenschaften ist schon mal ein nettes Resultat, aber noch besser wäre eine grafische übersicht über die Schriften.<\/p>\n Dazu gibt es den Bericht rptFonts<\/b>, der auf der Tabelle als Datensatzquelle basiert, dies jedoch über eine Abfrage, die nur die nicht fetten 10-Punkt-Schriften ausfiltert und sie aufsteigend nach Breite des ermittelten Textes sortiert. Das Ergebnis zeigt Bild 5. Für jede Schriftart wird zeilenweise der Teststring ausgegeben und grau hinterlegt.<\/p>\n Bild 5: Bericht zur Ausgabe aller 10-Punkt-Schriften (rptFonts)<\/span><\/b><\/p>\n Der Entwurf des Berichts (s. Bild 6) fällt recht spartanisch aus. Es gibt ein Textfeld, welches an den Namen der Schriftart gebunden ist (FName<\/b>) und sonst gähnende Leere.<\/p>\n Bild 6: Entwurfsansicht des Berichts rptFonts<\/span><\/b><\/p>\n Tatsächlich wird der Teststring erst zur Laufzeit gerendert. Im Unterschied zu Formularen kennen Access-Reports Zeichnungs- und Textausgabemethoden.<\/p>\n Die Anweisung Print <\/b>gibt einen Text an der zuvor festgelegten Stelle CurrentX <\/b>aus, wobei als Schriftart die herangezogen wird, die für den gesamten Bericht gesetzt wurde. Die entsprechende Ereignisprozedur zeigt Listing 1.<\/p>\n Listing 1: Code des Berichts zum Rendern der Schriftarten<\/span><\/b><\/p>\n Das Ereignis Beim Formatieren <\/b>wird immer ausgelöst, wenn Access einen Datensatz im Detailbereich rendern will. Für jede Schriftart, die im Detailbereich durch das Textfeld FName <\/b>als unterster Gruppierungsebene auftritt, wird die Event-Prozedur _Format <\/b>angesprungen. Dort werden zunächst die Schriftparameter FontBold<\/b>, FontName <\/b>und FontSize <\/b>des Berichts aus der Datensatzherkunft entnommen und anschließend der Teststring, der als Konstante im Modul mdlFontHeight <\/b>festgelegt ist, über die Print<\/b>-Anweisung gerendert, wobei erst noch die horizontale Ausgabekoordinate in CurrentX <\/b>auf 4000 <\/b>Twips (ca. 7 cm) gesetzt wird.<\/p>\n Dazwischen befindet sich noch ein Code-Schnipsel, welches den grauen Hintergrundrahmen rendert, wofür die Line<\/b>-Anweisung zum Einsatz kommt. Die Abmessungen dieses Hintergrundrechtecks werden über die Report<\/b>-Methoden TextWidth <\/b>und TextHeight <\/b>ermittelt, ähnlich wie bei der Wizhook<\/b>-Methode TwipsFromFont<\/b>, nur dass diese hier deutlich kürzer ausfallen, da sie die Parameter für die Schriftart bereits aus dem Bericht selbst beziehen.<\/p>\n Interessant ist, dass der Wert, der von diesen beiden Funktionen zurückgegeben wird, nicht immer mit dem übereinstimmt, was die Wizhook<\/b>-Funktion ermittelte. Beim ersten Aufruf des Berichts fällt nämlich auf, dass manche Zeilen in ihrer Länge nicht der Reihenfolge entsprechen.<\/p>\n Das Ergebnis weiter oben kam erst zustande – das wurde bisher unterschlagen -, nachdem eine Korrekturroutine über die Tabelle tblFontExtents<\/b> laufen gelassen wurde. Dafür ist der Bericht rptTest <\/b>der Datenbank zuständig, welcher im Prinzip so aufgebaut ist wie der Bericht rptFonts<\/b>. Wenn Sie ihn öffnen, sehen Sie nichts, da keine Print<\/b>-Anweisung enthalten ist. Dennoch wird jede Schriftart on the fly gerendert, wenn Sie bei den Navigationsschaltflächen den Button für Letzte Seite <\/b>anklicken. Auch hier wird jeweils das Ereignis Beim Formatieren <\/b>aufgerufen und in der Prozedur die Ausdehnung des Teststrings etwa per TextWidth <\/b>ermittelt. Statt der Print<\/b>-Anweisung steht danach aber eine Codezeile zur Korrektur der zugrunde liegenden Tabelle:<\/p>\n Erst nach dieser Korrektur stimmt die Pyramide im Bericht zur Schriftartenausgabe.<\/p>\n Schriften aussieben<\/b><\/p>\n Den Bericht kann man nun verwenden, um Schriftarten zu bestimmen, die besonders gut lesbar sind, aber trotzdem eine geringe Ausdehnung haben. Das ist indessen ein mühseliges Unterfangen, wenn Sie Aberhunderte von Fonts installiert haben, die für die Verwendung unter Access völlig sinnlos sind, wie Handschriftarten oder Symbolschriften. Darum gibt es in der Tabelle ein zusätzliches Boolean<\/b>-Feld Show<\/b>, welches standardmäßig auf True <\/b>steht.<\/p>\n Der Bericht filtert nämlich auch nach diesem Feld; Datensätze, die hier den Wert False <\/b>enthalten, kommen nicht zur Ansicht. Wie aber entscheiden Sie, bei welchem Schriftdatensatz das Häkchen entfernt werden sollte Der Name der Schrift reicht dafür ja nicht aus.<\/p>\n Dafür wurde das Formular frmFonts <\/b>erfunden, welches bereits weiter oben zu sehen war. Beim Klick auf einen Datensatz des Unterformulars wird das Label<\/b>-Feld mit dem Beispieltext ganz unten auf die entsprechende Schriftart gesetzt.<\/p>\n Filtern Sie das Unterdatenblatt zuvor am besten per Kontextmenü und lassen Sie etwa nur die Schriftgröße 12 <\/b>zu und die Einstellung Nicht-Fett. Beim Durchlaufen der Zeilen können Sie nun kontrollieren, welche Schriftart akzeptabel erscheint und deaktivieren für alle anderen das Häkchen der Spalte Show<\/b>. <\/p>\n Anschließend starten Sie noch die Abfrage qryFillFonts<\/b>. Sie überträgt alle Datensätze mit aktiviertem Show <\/b>in eine zweite Tabelle tblFonts<\/b>, wobei lediglich der Name der Schriftart berücksichtigt wird und außerdem Doppelungen herausgefiltert werden.<\/p>\n Auch diese Tabelle enthält ein Boolean<\/b>-Feld namens Favorite<\/b>, das zunächst auf True <\/b>steht. Sie erhalten über dieses Feld eine zusätzliche Kontrollmöglichkeiten, um bestimmte Schriften aus dem Bericht zu eliminieren, wenn es zu viele sind.<\/p>\n Der Bericht verwendet als Datensatzherkunft tatsächlich eine Abfrage, wie sie in Bild 7 zu sehen ist. Als Bedingungen sind Schriftgröße 10, Fett = Falsch und Favorit = Ja gesetzt. Sortiert wird aufsteigend nach per Korrektur ermittelter Laufweite Width2<\/b> des Teststrings.<\/p>\n Bild 7: Datensatzherkunft des Berichts rptFonts<\/span><\/b><\/p>\n Damit sich die Mühe gelohnt hat, inspizieren Sie den Bericht rptFonts <\/b>nun abermals. Weiter oben hat das Aussieben bereits stattgefunden und nur Fonts, die annähernd infrage kommen, sind aufgeführt. Schalten Sie in der Seitenansicht den Zoom auf 75% und kontrollieren Sie, welche Schriften nun noch lesbar abgebildet werden und gut aussehen.<\/p>\n Interessant ist, dass die Schrift Calibri <\/b>wirklich zu den Spitzenreitern zählt. Sie hat keine Makel, was die Lesbarkeit angeht und die Laufweite ist deutlich geringer, als etwa bei Arial<\/b>. Es gibt aber durchaus Konkurrenz: Corbel<\/b>, Tunga <\/b>und Gill Sans <\/b>können offenbar mithalten. Bei näherer Betrachtung stellt man fest, dass der Schein trügt. Denn die Zeichenhöhe von Tunga <\/b>etwa ist deutlich kleiner, als die von Calibri<\/b>. Man müsste also etwa 11pt-Tunga <\/b>mit 10pt-Calibri <\/b>vergleichen.<\/p>\n Genau dafür gibt es das Formular frmFontsBlock <\/b>in der Beispieldatenbank. Darin sind zwei Labels mit Beispieltext transparent exakt übereinander gelegt, und für beide lässt sich die Schriftart und -größe separat einstellen.<\/p>\n Zur Unterscheidung ist die Schriftart des einen Labels auf Blau gesetzt. In Bild 8 ist für das zweite Label statt Tunga <\/b>die Schrift Blue Highway <\/b>ausgewählt – sie stand in Bild 5 an oberster Stelle und hatte demnach die geringste Laufweite. Erst, nachdem Calibri <\/b>auf 10pt <\/b>und Blue Highway <\/b>auf 12pt <\/b>gesetzt werden, sind die Zeichenhöhen aber weitgehend identisch! Das ändert die Einschätzung für Blue Highway <\/b>natürlich. Zwar ist der blaue Text in der Ausdehnung nun immer noch geringfügig kürzer, doch bei Abwägungen zur Lesbarkeit würde Calibri <\/b>eher der Vorzug gegeben werden.<\/p>\nHKEY_CURRENT_USER\\Software\\Microsoft\\VBA\\7.0\\Common<\/pre>\n
![\"Einzelne](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_002.png\")
<\/p>\n![\"Datenblattformular](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_003.png\")
<\/p>\n![\"Unterdatenblatt](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_004.png\")
<\/p>\nTestString \"Beispieltext: Demo-Datenbank für AiU, Ausgabe 6\/2014\"<\/pre>\n
![\"Bericht](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_005.png\")
<\/p>\n![\"Entwurfsansicht](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_006.png\")
<\/p>\nPrivate Sub <\/span>Detailbereich_Format(Cancel As Integer<\/span>, FormatCount As Integer<\/span>)\r\n Dim <\/span>W As Long<\/span>, H As Long<\/span>\r\n With<\/span> Me\r\n .FontBold = Me!FBold.Value\r\n .Fontname = Me!FName.Value\r\n .Fontsize = Me!FSize.Value\r\n W = .TextWidth(TestString)\r\n H = .TextHeight(TestString)\r\n Me.Line (4000, 0)-(4000 + W, H), &HE0E0E0, BF\r\n .CurrentX = 4000\r\n .CurrentY = 0\r\n .ForeColor = 0\r\n .Print TestString\r\n End With<\/span>\r\nEnd Sub<\/span><\/pre>\nCurrentDb.Execute _\r\n \"UPDATE tblFontExtents \" & _\r\n \"Set<\/span> Width2 = \" & W & _\r\n \", Height2 = \" & H & _\r\n \" WHERE ID = \" & Me!ID.Value<\/pre>\n![\"Datensatzherkunft](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_008.png\")
<\/p>\n![\"Zwei](\"..\/fileadmin\/_temp_\/2014_06\/pic_957_009.png\")
<\/p>\n