Rechtslage Datenblätter von älteren ICs veröffentlichen

Thomas Belau · Jul 19, 2003

MaWin wrote:

Browst du nun HTML oder XML ? DTD sind XML. XML ist nicht http:
Kein Browser muss irgendwie auf DTD reagieren. DTD ist ein Syntaxfehler.

Neee, eine DTD stammt aus SGML. Und HTML war als subset davon konzipiert.
XML kam später (und XHTML noch viel später). Und da hat man mittlerweile
die DTD abgeschafft und durch Schema ersetzt. Und eine DTD-Angabe wie

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">

ganz oben im Dokument ist kein Fehler.

Wenn irgendwelche proprietaere Software in ihren Output irgendwie eine
DTD reinfummelt, die nur vom Microsoft Internet Explorer korrekt
verstanden wird, dann ist die Software schlicht und einfach fehlerhaft.

Genau das soll ja vermieden werden. I.d.R. fürhren die Browser die
HTML-DTD's intern mit. Darin gibt es dann erweiterungen. Es ist auch
fraglich, ob sich jeder Browser daran hält. Es ist aber zumindest ein Weg...

Die Methode ist schon anno dazumals im Buch ueber IBMs success story
nachzulesen gewesen, Billy-Boy hat's gut verinnerlicht, leider fallen
seine Konkurrenten und Kunden immer noch drauf rein. Du auch.

Wie kommst Du denn auf das schmale Brett? Der IE wird bei mir nur benutzt,
um festzustellen, ob die armen diesen Browser benutzenden Schweine mit
meinen Sachen auch etwas anfangen können. Davon ab läuft bei mir Linux seit
0.99pl14 (Wintwr 1993)!

[Und bei der angesprochenen Seite gibt es keinen, aber auch gar keinen
Grund fuer solche 'Features' wie DTD, die Seite geht problemlos auch ohne
so einen Kram zu formulieren, in einem HTNML das jeder Browser versteht]

Da wollte ich nicht dagegen reden. Auch habe ich immer brav Konjunktive
verwendet ("kann" nicht "muß"). Sollte es aber irgendwann nicht mehr
funktionieren, ist es leichter, Sowas wie oben reinzuschreiben als
meinetwegen alle CENTER-Tags zu ersetzen. Und das ist Standardgemäß!

In einem Punkt gebe ich Johannes Bauer allerdings Recht. Die Kommentar Tags
sollten wirklich irgendwann mal zu "" umgebaut werden.

Ach ja MaWin: Fällt Dir etwas Besseres ein, um die FONT-Tags weg zu
bekommen? CSS und mehr geht nicht. Das macht aber jede Menge Arbeit und
lohnt bei bestehenden Seiten nur begrenzt. Bei diesen Tags ist es richtig,
daß sie nie Bestandteil des Standards waren und von M$ eingeführt wurden.
Das war aber in der Phase, als die Browser Produzenten noch miteinander
geredet haben. Und verstehen viele Browser das. Es ist De Facto Standard.

MfG
Thomas Belau

MaWin · Jul 19, 2003

Thomas Belau <thomas.belau@z1013.de> schrieb im Beitrag <bfavgm$osq$1@online.de>...

Neee, eine DTD stammt aus SGML.

Irgendwo liegt hier die Doku zu SGML, aber ich erinnere mich
nicht an eine DTD darin und bin zu faul die Doku zu suchen.
Also: Mag sein.

Und HTML war als subset davon konzipiert.

Und enthaelt keine DTD.

XML kam später

Ja.

(und XHTML noch viel später).

Ja.

Und eine DTD-Angabe wie
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd"
ganz oben im Dokument ist kein Fehler.

Sicher doch. Zunaechst mal schon ein konzeptioneller Fehler, denn sie geht

davon aus, das die w3.org auf immer und ewig ueber http erreichbar ist wenn
mal irgendjemand das Dokument lesen will. Nichts ist weniger haltbar als eine
URL. Papyrus haelt 4000 Jahre ! Deppen-Fortschritt. Nur Trottel glauben an
solche wackeligen Definitionen.

Zu dem ist sie nicht Bestandteil von HTML (sondern erkennbar ein Kommentar)
und darf daher keine Information beibringen, die zur Anzeige des Dokuments
in einem einfacheren HTML Standard (1.0 oder so) notwendig sind.
Fuer den faengt das Dokument mit <HTML> an und sonst nix.

Sollte es aber irgendwann nicht mehr
funktionieren, ist es leichter, Sowas wie oben reinzuschreiben als
meinetwegen alle CENTER-Tags zu ersetzen. Und das ist Standardgemäß!

Es gibt keinen vernuenftigen Grund, in existierenden Dokumenten (die

offenbar erkennbar richtig dargestellt werden) die CENTER Tags zu
ersetzen. Never change a running program. Inkompatibilitaet erzeugt man
durch nutzloses Aendern an Bestehendem. Dann reden sich Leute noch ein,
das das 'besser' waere. Grube auf, Leute rein, Grube zu.

Wer Seitengestaltung machen will, soll ein angemessenes Dateiformat
dafuer verwenden, wie PDF oder TeX, und nicht Jahr fuer Jahr an einem
eigentlich nicht dafuer gedachten Format (HTML) durch irgendwelche
halbdurchdachten Aenderungen rumbasteln.

Ach ja MaWin: Fällt Dir etwas Besseres ein, um die FONT-Tags weg zu
bekommen?

Wozu FONT Tags ? <H1> oder <dd> reicht doch. Warum willst du dem Leser
aufzwingen, in welcher Schrift er sich das Dokument ansehen soll ?
Er hat doch absichtlich in seinem Browser Einstellungen fuer Schriftart
(proportional und monospaced) gemacht und absichtlich sich eine fuer ihn
gut lesbare Groesse ausgesucht. Warum willst du den Anwender entmuendigen ?
Warum haeltst du den Anwender fuer Unfaehig sich die richtige Schrift
auszusuchen ? Warum willst du die Wahl des Anwenders ignorieren ? Warum
masst du dir das an ?

Bei diesen Tags ist es richtig,
daß sie nie Bestandteil des Standards waren und von M$ eingeführt wurden.

Wenn du gerne 'Verdana' haettest, was soll der Benutzer praesentiert
bekommen, der keine Verdana Schriftart auf seinem Rechner hat ?
Wenn dir Schriftart irgendwie wichtig ist, z.B. bei Herstellerlogos,
dann darfst du ein GIF integrieren, dessen Explanation den
dargestellten Text noch mal enthaelt, fuer Leute ohne Graphikbildschirm.

Wenn eine irgendwie geartete Schriftartdefinition nicht auch das Aussehen
der Zeichen definiert (wie embedded Font in PDF), ist sie sinnlos. Nur
das Produkt von Trotteln, die nicht wissen, welchen Code und welche
Datendefinition man zum Rendern der Glyphs einer Schrift braucht. Solche
Trottel gibt es aber gerade bei den Kindereien im WEB reichlich.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx.net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Holger Bruns · Jul 19, 2003

On Sat, 19 Jul 2003 10:27:06 +0200, Thomas Belau <thomas.belau@z1013.de>
wrote:

Ach ja MaWin: Fällt Dir etwas Besseres ein, um die FONT-Tags weg zu
bekommen? CSS und mehr geht nicht. Das macht aber jede Menge Arbeit und
lohnt bei bestehenden Seiten nur begrenzt. Bei diesen Tags ist es richtig,
daß sie nie Bestandteil des Standards waren und von M$ eingeführt wurden.
Das war aber in der Phase, als die Browser Produzenten noch miteinander
geredet haben. Und verstehen viele Browser das. Es ist De Facto Standard.

Man kann bei HTML und solchen Sachen nicht von Standard reden, höchstens
vom Konkurrenzkampf durch gewollte Inkonsistenzen, durch die Browser der
Konkurrenz ausgebootet werden sollen. Unterstützt wird das durch Deppen,
die sowas für technischen Fortschritt halten, die dem hinterherhecheln.
Der Anwender bleibt auf der Strecke und muß sich mit Webseiten quälen,
die von den Spinnern so programmiert wurden, das eine Darstellung auf
dem eigenen Rechner oft ausscheidet. Ich habe das für mich so geregelt:
Wer mich mit inkompatiblen Spielereien nervt, dessen Domain wandert in
einen Filter, denn eine Fehlermeldung ist mir allemal lieber als ein
System, das Buchstaben- und Datensalat liefert und mir womöglich noch
meinen Rechner zerlegt. Mir sind Computeridioten schon immer ein Dorn im
Auge gewesen.

Holger

Thomas Belau · Jul 19, 2003

MaWin wrote:

Und HTML war als subset davon konzipiert.

Und enthaelt keine DTD.

Dann schau Dir a) die HTML Spezifikationen an und b) wenn HTML ein subset
von SGML ist, muß auch eine DTD existieren, die dieses subset definiert.
Simpelste Logik.

Sicher doch. Zunaechst mal schon ein konzeptioneller Fehler, denn sie geht
davon aus, das die w3.org auf immer und ewig ueber http erreichbar ist
wenn mal irgendjemand das Dokument lesen will. Nichts ist weniger haltbar
als eine URL. Papyrus haelt 4000 Jahre ! Deppen-Fortschritt. Nur Trottel
glauben an solche wackeligen Definitionen.

Denkste! In der HTML Spezifikation steht auch irgendwo, daß mit der Zeile
nichts geladen wird. Der Browser hat die Pflicht, wenn er das denn
auswertet, die DTD zum DOCTYPE zu enthalten. Wie die interne Umsetzung im
Browser aussieht ist eine andere Frage.

Zu dem ist sie nicht Bestandteil von HTML (sondern erkennbar ein
Kommentar) und darf daher keine Information beibringen, die zur Anzeige
des Dokuments in einem einfacheren HTML Standard (1.0 oder so) notwendig
sind. Fuer den faengt das Dokument mit <HTML> an und sonst nix.

Nein, die Zeile ist kein Kommentar. "<!DOCTYPE" und "<!--" sind zwei
verschiedene Schuhe. Es handelt sich in beiden Fällen um SGML-Anweisungen.

Es gibt keinen vernuenftigen Grund, in existierenden Dokumenten (die
offenbar erkennbar richtig dargestellt werden) die CENTER Tags zu
ersetzen. Never change a running program. Inkompatibilitaet erzeugt man
durch nutzloses Aendern an Bestehendem. Dann reden sich Leute noch ein,
das das 'besser' waere. Grube auf, Leute rein, Grube zu.

Sag' ich doch. Außerdem hatte ich glaube ich von den FONT-Tags geredet oder?

Wer Seitengestaltung machen will, soll ein angemessenes Dateiformat
dafuer verwenden, wie PDF oder TeX, und nicht Jahr fuer Jahr an einem
eigentlich nicht dafuer gedachten Format (HTML) durch irgendwelche
halbdurchdachten Aenderungen rumbasteln.

Das stimmt so auch nicht. Es ist richtig, daß HTML für die Seitengestaltung
nicht gedacht war. Es enthält ja auch nur Elemente zur Strukturierung des
Textes. Das hat sich mit CSS aber geändert. Und PDF: klar, wer auf
Meldungen wie "Font xxx not found" oder erstmal nicht leserliche weil
komprimierte Dokumente (Atmel) oder so steht... Ich will nicht zu laut
schreien, aber gerade PDF ist sehr proprietär und M$ zentriert.

? Warum haeltst du den Anwender fuer Unfaehig sich die richtige Schrift
auszusuchen ? Warum willst du die Wahl des Anwenders ignorieren ? Warum
masst du dir das an ?

Warum nicht? Man kann seinen Browser auch so einstellen, daß er solche
Sachen ignoriert. Ich persönlich bin auf Leserlichkeit angewiesen. Deswegen
habe ich genau das auch getan. Aus dem Netz wird 10pt als minimale Größe
verwendet. Geht das mit dem IE etwa nicht? Also ist auch in meinen eigenen
CSS-Dateien keine Schrift kleiner als 10pt. Und die Angabe in Punkt ist auf
jedem Monitor gleich groß (3,5mm) UND leserlich. Ich will, kann und darf
mit CSS Seiten gestalten. Also habe ich jedes Recht dazu das zu tun.

Bei diesen Tags ist es richtig,
daß sie nie Bestandteil des Standards waren und von M$ eingeführt wurden.

Wenn du gerne 'Verdana' haettest, was soll der Benutzer praesentiert
bekommen, der keine Verdana Schriftart auf seinem Rechner hat ?
Wenn dir Schriftart irgendwie wichtig ist, z.B. bei Herstellerlogos,

Da hängt doch mehr dran als der Schnitt. Auch die Auszeichnungen etc.
werden mit dem Tag festgelegt.

dann darfst du ein GIF integrieren, dessen Explanation den

Nein, darfst Du eigentlich nicht. Da hat CompuServe was dagegen. Deswegen
gibt es PNG als "offiziellen" Nachfolger.

das Produkt von Trotteln, die nicht wissen, welchen Code und welche
Datendefinition man zum Rendern der Glyphs einer Schrift braucht. Solche
Trottel gibt es aber gerade bei den Kindereien im WEB reichlich.

Das interessiert die "Trottel" auch nicht. Willst Du wirklich wissen, wie
AcroRead seine Zeichen rendert? Oder reicht Dir das Aussehen nicht? Es gilt
nur eine einzige Forderung für Text: leserlich soll er sein. Und des
Doktors Seite IST leserlich, auch wenn er ein paar nicht (mehr)
standardgerechte Tags drinne hat.

MfG
Thomas Belau

MaWin · Jul 19, 2003

Thomas Belau <thomas.belau@z1013.de> schrieb im Beitrag <bfbehi$8bm$1@online.de>...

Dann schau Dir a) die HTML Spezifikationen an

Keine DTD (in fuer die Seite angemessenen Versionen wie 1.0 und 2.0,
den Wildwuchs seit dem Browserkrieg kritisiere ich ja gerade).

und b) wenn HTML ein subset
von SGML ist, muß auch eine DTD existieren, die dieses subset definiert.
Simpelste Logik.

Falsch geschlussfolgert.

Und der Rest ist nicht besser, aber wohl unbelehrbar, siehe:

Warum nicht?
-----
Da hat CompuServe was dagegen.

Gehoert natuerlich zu den traurigen Kapitel von vermurkster
Firmenpolitik mit Softwarepatenten, gegen die ich wohl schon
ausreichend gewettert habe, hat sich aber mit der Pleite von
CompuServe (1998?) auf gerechte Art von selbst geregelt.
CompuServe gibt es heute nicht mehr, die sind jetzt nur noch
ein Produktstempel von AOL und AOL hat das GIF Patent nie
weiter verfolgt, zu dem ist das LZW Patent (2002?) ausgelaufen.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx.net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Axel Schwenke · Jul 19, 2003

Thomas Belau <thomas.belau@z1013.de> wrote:

MaWin wrote:

Wer Seitengestaltung machen will, soll ein angemessenes Dateiformat
dafuer verwenden, wie PDF oder TeX, und nicht Jahr fuer Jahr an einem
eigentlich nicht dafuer gedachten Format (HTML) durch irgendwelche
halbdurchdachten Aenderungen rumbasteln.

Das stimmt so auch nicht. Es ist richtig, daß HTML für die Seitengestaltung
nicht gedacht war. Es enthält ja auch nur Elemente zur Strukturierung des
Textes.

Soweit ACK.

Das hat sich mit CSS aber geändert.

Nein! Auch CSS enthalten lediglich *Vorschläge*, wie der Browser
bestimmte Inhalte rendern könnte. Der Browser darf (bei mir: wird)
das auch komplett ignorieren.

Und PDF: klar, wer auf
Meldungen wie "Font xxx not found" oder erstmal nicht leserliche weil
komprimierte Dokumente (Atmel) oder so steht... Ich will nicht zu laut
schreien, aber gerade PDF ist sehr proprietär und M$ zentriert.

Blödsinn. PDF stammt von Adobe. Abgesehen von einigen Neuerungen
(z.B. PDF-"Formulare"), die den Zweck eines *Ausgabeformats* ad absurdum
führen, ist PDF bemerkenswert sauber designt und vor allem lückenlos
dokumentiert.

? Warum haeltst du den Anwender fuer Unfaehig sich die richtige Schrift
auszusuchen ? Warum willst du die Wahl des Anwenders ignorieren ? Warum
masst du dir das an ?

Warum nicht? Man kann seinen Browser auch so einstellen, daß er solche
Sachen ignoriert. Ich persönlich bin auf Leserlichkeit angewiesen. Deswegen
habe ich genau das auch getan. Aus dem Netz wird 10pt als minimale Größe
verwendet.

Wie groß sind 10pt auf dem Monitor? Windows z.B. stellt alle Schriften
deutlich größer dar, weil es von 72dpi Bildschirmauflösung ausgeht.
Mein Bildschirm hat aber 110dpi. Das, was der HTML-"Designer" für eine
angemessene Schriftgröße hält, kommt bei mir als Fliegendreck an.

XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau

Thomas Belau · Jul 20, 2003

Axel Schwenke wrote:

Das hat sich mit CSS aber geändert.

Nein! Auch CSS enthalten lediglich *Vorschläge*, wie der Browser
bestimmte Inhalte rendern könnte. Der Browser darf (bei mir: wird)
das auch komplett ignorieren.

Sag' ich doch. Jeder kann seinen Browser einstellen, wie er will. Er kann
eben auch CSS ignorieren. Trotzdem verwende ich für meinen Kram CSS.

Blödsinn. PDF stammt von Adobe. Abgesehen von einigen Neuerungen
(z.B. PDF-"Formulare"), die den Zweck eines *Ausgabeformats* ad absurdum
führen, ist PDF bemerkenswert sauber designt und vor allem lückenlos
dokumentiert.

Ähhh, stimmt ganz bestimmt. Nur bringt der Reader keine Fonts mit und der
Destiller kann Referenzen auf externe Fonts verwenden (das meinte ich mit
"proproetär"). Böse, wenn jemand dann einen Font benutzt, den ich gerade
nicht parat habe. Es wäre clever von Adobe eine Tabelle mit Fontaliases zu
verwalten. Unter X kann ich das aber auf meinem iPaq geht das z.B. nicht.

Und PDF war von vorn herein als "Ersatz" für HTML gedacht. Es hat sich nur
nicht durchgesetzt. Immerhin ist es wann aufgekommen? 1995 ungefähr? Da war
HTML 2.0 noch nicht mal richtig eingeführt und alle haben darüber
gemeckert. Der Kampf war aber kurz. Hat wohl was mit den Kosten zu tun.

Wie groß sind 10pt auf dem Monitor? Windows z.B. stellt alle Schriften
deutlich größer dar, weil es von 72dpi Bildschirmauflösung ausgeht.
Mein Bildschirm hat aber 110dpi. Das, was der HTML-"Designer" für eine
angemessene Schriftgröße hält, kommt bei mir als Fliegendreck an.

Hmmm. ich habe das ausgerechnet. Typographischer Punkt: 1pt=1/72". Deswegen
ist das immer gleich groß. Die Probleme treten auf, wenn man mit Pixels
anfängt. Ich habe gerade mal das Lineal an meinen Moni gehalten. Er wird
mit 75dpi betrieben. Und die Zeichenhöhen stimmen. Hast Du evtl. vergessen,
die Unterlängen mitzumessen?

MfG
Thomas Belau

Bertram Geiger · Jul 20, 2003

Thomas Belau schrieb:

Axel Schwenke wrote:

....

Ähhh, stimmt ganz bestimmt. Nur bringt der Reader keine Fonts mit und der
Destiller kann Referenzen auf externe Fonts verwenden (das meinte ich mit
"proproetär"). Böse, wenn jemand dann einen Font benutzt, den ich gerade
nicht parat habe.

Fonts einbetten beim 'Distillieren'sollte das doch lösen ?

Es wäre clever von Adobe eine Tabelle mit Fontaliases zu

verwalten. Unter X kann ich das aber auf meinem iPaq geht das z.B. nicht.
....

mfg Bertram

--
Bertram Geiger <bgeiger@aon.at>
HTL-Bulme Graz, Austria

MaWin · Jul 20, 2003

Thomas Belau <thomas.belau@z1013.de> schrieb im Beitrag <bfdn9t$4lg$1@online.de>...

Oje, diese Unkenntnis. Mal ein bischen was zur Klaerung:

Ähhh, stimmt ganz bestimmt. Nur bringt der Reader keine Fonts mit

Doch. 5 Standardfonts.

und der Destiller kann Referenzen auf externe Fonts verwenden

Kann er, wenn man ihn explizit dazu auffordert, was Adobe nicht empfiehlt.
Aber er kann auch und vor allem die verwendeten Fonts embedden, also in
die Datei aufnehmen, und das ist natuerlich der richtige Weg, sobald man
einen der nicht Standardfonts verwendet.
Das Atmel das nicht tut, zeigt, das jemand bei Atmel bloed ist.
Kommt vor, hat aber nix mit PDF zu tun.

Und PDF war von vorn herein als "Ersatz" für HTML gedacht.

Nein. PDF ist komprimiertes Postscript mit ein bischen Zusatzkram wie
Dokumentinfos, Navigation, eben embeddeten Bildern und Fonts und ist
und war schon immer als 100% portables Seitenlayout mit 100% exakter
Darstellung gedacht, wenn Layout wichtig ist. Also zum Drucken,
der Nachfolger von EPS.

PDF 'fehlt' (im Vergleich zu HTML) das Dokumente je nach Bildschirmbreite
neu umgebrochen werden koennen (siehe Windows Help WinHelp 3.x, der kann das
und kann auch ansonsten viel mehr als HTML), und die Links (URLs). Damals
fehlte PDF noch die Eingabefelder, die gibt es erst seit PDF Forms. Frames
fehlen nicht wirklich

Es hat sich nur nicht durchgesetzt.

Hat es sich seit dem das Dateiformat offen ist. Praktisch alle *Dokumente*
im WWW sind inzwischen in PDF. Vorher war es zu teuer, richtig.

Immerhin ist es wann aufgekommen?

Als Postscript so 1986.

1995 ungefähr? Da war

Als PDF mag 1995 hinkommen, damals war es jedoch tatsaechlich proprietaer.

HTML 2.0 noch nicht mal richtig eingeführt und alle haben darüber
gemeckert.

Peinlich, wenn man sich anschaut wie die HTML-Entwickler, obwohl die
bessere Alternative direkt vor ihren Augen lag, in ihren eigenen Formaten
(HTML 1.0/2.0/...) so viel uebersehen haben, so viel falsch gemacht haben,
jede Woche eine Aenderung brauchten weil das Alte nix getaugt hat. Sie
haetten sich nur EIN MAL Postscript/PDF ansehen muessen und haetten all
ihre Fehler vermeiden koennen. Aber nein, 'not invented here' und 'wir
sind die Kluegsten' fuehrt dann zu solchem Quark wie HTML.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx.net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Axel Schwenke · Jul 20, 2003

Thomas Belau <thomas.belau@z1013.de> wrote:

Axel Schwenke wrote:

Blödsinn. PDF stammt von Adobe. Abgesehen von einigen Neuerungen
(z.B. PDF-"Formulare"), die den Zweck eines *Ausgabeformats* ad absurdum
führen, ist PDF bemerkenswert sauber designt und vor allem lückenlos
dokumentiert.

Ähhh, stimmt ganz bestimmt. Nur bringt der Reader keine Fonts mit und der

Der Reader kennt zumindest die Fontmetrics der Standardfonts und ein
Mapping derselben auf Systemfonts (Acrobatreader ist für Plattformen
ohne Fonts ziemlich sinnlos - wobei: pdftotxt existiert).

Destiller kann Referenzen auf externe Fonts verwenden (das meinte ich mit
"proproetär"). Böse, wenn jemand dann einen Font benutzt, den ich gerade
nicht parat habe.

Achso, das meinst du. Ja klar, man kann auch kaputte PDFs bauen. Das
ist dann das moralische Äquivalent zu <FONT "MS-Comics"> in HTML.

Es wäre clever von Adobe eine Tabelle mit Fontaliases zu
verwalten. Unter X kann ich das aber auf meinem iPaq geht das z.B. nicht.

Aha. Der Acrobatreader für iPaq ist also Mist. Dann sag das doch.

Und PDF war von vorn herein als "Ersatz" für HTML gedacht.

Wohl kaum. PDF war gedacht als Nachfolger von Postscript. Der Fokus
liegt bei beiden Formaten auf einer möglichst exakten Beschreibung,
wie der Inhalt *gerendert* aussehen soll. Damit taugen die Formate
für die Druckvorstufe oder für papierlose Dokumente.

XL
--
Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition,
die anderen sind einfach von sich aus unlogisch. -- Anselm Lingnau

Thomas Belau · Jul 20, 2003

Axel Schwenke wrote:

Der Reader kennt zumindest die Fontmetrics der Standardfonts und ein
Mapping derselben auf Systemfonts (Acrobatreader ist für Plattformen
ohne Fonts ziemlich sinnlos - wobei: pdftotxt existiert).

Ack! Ich megablind. Der Reader bringt die üblichen Verdächtigen in Form von
Postscriptfonts mit. Das mit dem Mapping geht seit V5.0 auch.

Aha. Der Acrobatreader für iPaq ist also Mist. Dann sag das doch.

Das hast Du gesacht! Es ging ums Fontmapping und nicht darum wie wo was
Mist ist.

wie der Inhalt *gerendert* aussehen soll. Damit taugen die Formate
für die Druckvorstufe oder für papierlose Dokumente.

Naja, so hatte ich das auch verstanden. "papierlose Dokumente". Vertrieb
über das WEB und so. Ich muß mal schauen, ob ich alte Adobe Werbung finde...

MfG
Thomas Belau

MaWin · Jul 20, 2003

Thomas Belau <thomas.belau@z1013.de> schrieb im Beitrag <bfe104$dke$2@online.de>...

Fällt außer mir noch jemandem auf, daß wir vollkommen OT sind?!?

Das kommt oefters vor.

Mit genau diesem Ausgangsgrund:
Ueberzogenem HTML.
Vom Gegenteil gab es noch nie einen OT-Thread.

Es gibt aber leider immer wieder Leute, die es bei HTML unnoetig
ueberziehen.
Und die so komplett lernresistent sind, das es zu endlosen Threads
fuehrt, in denen es jeweils mehrere Leute versuchen, sie von ihrem
Irrglauben abzubringen.

Leider muss man das aber offenbar Jedem einzelnen einzeln erklaeren.

In diesem Thread halt dir.

Obwohl Google eigentlich gereicht haette, um jedem WebDesigner
klar zu machen, das das, was die Benutzer sich wuenschen, nicht
das ist, was die Computerbild gerade bewirbt.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx.net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Robert Rottmerhusen · Jul 20, 2003

Moin MaWin,

PDF ist ueblicherweise komprimiert, und AcroRead kann die ueblicherweise
darstellen. Wenn das Dokument falsch komprimiert ist, dann moeglicherweise
weil ein fehlerhaftes Programm zur Dokumenterzeugung verwendet wurde.

z.B. Acrobat 4.x Tools wie Distiller und PdfWriter. Deren Dokumente
kann der Acrobat Reader 6.0 teilweise nicht lesen. Man bekommt ne
blanke Seite.
Reader 4.x geht aber problemlos.

Das mit den externen Fonts stammt in der Hauptsache aus Unis. Die cleveren
sparen gern Platz.

Clever. Aha.

Sind doch Unis ;-)

Ich habe bisher 2 Programme geschrieben, die (spezielle) PDF Dokumente
direkt per Programmcode erzeugen. Es geht. Es ist kein Problem. Man muss
dazu noch nicht mal jeden Befehl generieren, der im PDF Referenzbuch
steht. Sondern nur die, die man braucht.

Jo, geht ganz gut. Für einface PDFs reicht ein Texteditor.
Komprimierung kann man ja weglassen.

Grüsse
Robert

Rechtslage Datenblätter von älteren ICs veröffentlichen

Thomas Belau

Guest

MaWin

Guest

Holger Bruns

Guest

Thomas Belau

Guest

MaWin

Guest

Axel Schwenke

Guest

Thomas Belau

Guest

Bertram Geiger

Guest

MaWin

Guest

Axel Schwenke

Guest

Thomas Belau

Guest

MaWin

Guest

Robert Rottmerhusen

Guest

Welcome to EDABoard.com

Sponsor

Online statistics

Forum statistics

Rechtslage Datenblätter von älteren ICs veröffentlichen

Thomas Belau

Guest

MaWin

Guest

Holger Bruns

Guest

Thomas Belau

Guest

MaWin

Guest

Axel Schwenke

Guest

Thomas Belau

Guest

Bertram Geiger

Guest

MaWin

Guest

Axel Schwenke

Guest

Thomas Belau

Guest

MaWin

Guest

Robert Rottmerhusen

Guest

Log in

Welcome to EDABoard.com

Sponsor