Größe von K und 2

@NordicStorm
Also entweder hast du das K grafisch dargestellt.
Dann wird die Größe lediglich dadurch beeinflusst wie viele Pixel verwendet wurden um das K darzustellen, weil es einfach nur ein Bild ist (wie ein Foto oder so)

Wenn du das K oder die 2 als Wert hast, dann ist es eine Datenmenge... ein Wert
Wikipedia: Datenmenge scroll dafür mal runter bis "Beispiele für Datenmengen"

@zaeld
@deponianer

zaeld schrieb:Vor allem hängt das vom verwendeten Font ab.

Diese Aussage würd ich so nicht unterstützen.

Bei Kompression:
Hier kommt es drauf an, wie die Pixel angeordnet sind.
Wenn eine Schriftart ein Zeichen größer oder kleiner Darstellt, kann sich dies positiv oder negativ auf die Kompression auswirken. Selbst Zeichen mit mehr Pixeln können kleiner sein, wenn sie eine natürliche Ordnung aufweisen.

Stell dir mal ein Bild vor, welches 1x1000 Pixel groß ist, und dessen ersten 20 Pixel Transparent und die restlichen 980 Schwarz sind. Nehmen wir an, das ist die Rasterung eines Zeichens.
Nehmen wir jetzt zusätzlich einen einfachen Kompressionsalgorithmus an, der statt der 1000 Pixel nur das speichert (Umgangssprachlich ausgedrückt):
"21-1000 Schwarz"

Soweit, so gut.

Nun stell dir ein anderes Bild vor, welches ebenfalls 1x1000 Pixel ist. Und alle Pixel transparent sind, nur jeder 100ste Pixel ist schwarz. D.h. es hat nur 10 schwarze Pixel. Die Bilddatei des Zeichens wäre deiner Ansicht nach kleiner. Schauen wir uns aber nun die komprimierte Datei an, so sieht dies ganz anders aus:
"100, 200, 300, 400, 500, 600, 700, 800, 900, 1000 Schwarz"

Selbst ausgefeiltere Komprimierungsalgorithmen können dabei nicht ändern, dass eine natürlich vorhandene Ordnung immer zu kleineren Archiven führt.

Und aus diesem Grund spielt hier die Interpolationsart, die der Rasterizer benutzt, eine Rolle. Die sorgt nämlich unter Umständen dafür, dass neben Transparent und Schwarz noch Kombinationen beider auftreten, und schon lässt sich das ganze schlechter komprimieren. Oder die Interpolation macht sowas eben nicht und benutzt nur vorhandene Farben.

Ohne Kompression:
Hier kommt es auf das Dateiformat an. Wenn ein Format explizit jeden Pixel mit derselben Genauigkeit speichert, dann haben alle Dateien derselben Auflösung dieselbe Größe und es ist unerheblich, wie viele Pixel gerastert wurden.

@Quimbo

Ich glaube, wir wissen ja immer noch nicht, was die eigentliche Frage war.

Wenn es darum geht, wie einzelne Zeichen eines Fonts auf der Platte gespeichert werden, hast du sicherlich recht. Hier kommt es dann auch wieder darauf an, ob es sozusagen ein Pixel-Font ist oder ob die Zeichen mit Vektoren konstruiert sind.

Der Font in den Arbeitsspeicher geladen wird aller Wahrscheinlichkeit nach unkomprimiert gespeichert, sodaß es dann nach der Breite des Zeichens geht. Ich hatte das so verstanden, daß es genau darum geht.

Allerdings paßt dann die Angabe des Beispiels mit zwei Byte für 'K' wieder nicht so ganz...

Z.

@zaeld

Das mit den 2 Byte für '2' war verwirrend und sollten wir ignorieren.

Ich hab das jetzt so verstanden, dass OP quasi wissen möchte, ob ein angezeigtes Zeichen mit mehr Pixeln auch mehr Speicherplatzbedarf hat. Dabei ist zu bemerken, dass das angezeigte Bild auf dem Monitor ebenfalls eine Datei ist, da es ja intern irgendwie gespeichert werden muss vor der Anzeige (Framebuffer).

zaeld schrieb:Der Font in den Arbeitsspeicher geladen wird aller Wahrscheinlichkeit nach unkomprimiert gespeichert

Soweit ich weiß, verwendet z.B. TrueType auch eine Art der Kompression, indem der Autor der Schrift bereits manuell wiederkehrende Muster erstellt, und diese dann nur noch in der Schrift instanziiert. Ich glaube es gibt auch Schriftformate, die von Hause aus LZ komprimiert werden.

Außerdem könnte je nach Treiber der Framebuffer komprimiert sein, so dass im angezeigten Bild wieder die Kompression eine Rolle spielt.

@NordicStorm
Das K steht denke ich als Abkürzung für 1000, also Kilo. 2k steht für 2000.
Oder denke ich da falsch ?

@Alek-Sandr
Ihm geht es tatsächlich um die Zeichen K und das Zeichen 2.. also den Buchstaben und die Zahl

Sorry, das ich mich wenig beteilige, viel zu tun in letzter Zeit!

@deponianer

deponianer schrieb am 10.10.2014:Ihm geht es tatsächlich um die Zeichen K und das Zeichen 2.. also den Buchstaben und die Zahl

Richtig!

@Alek-Sandr

Alek-Sandr schrieb am 10.10.2014:Das K steht denke ich als Abkürzung für 1000, also Kilo. 2k steht für 2000.
Oder denke ich da falsch ?

Ja, da denkst du falsch, hätte ich das gemeint, müsste ich, denke ich keinen Thread erstellen^^

JETZT, weiß ich nicht mehr wirklich weiter.
Jeder fasst es anders auf :P
Ich meine keine Speichertypen speziell. Kein Font oder ähnliches.

Ich formuliere es noch anders: Nehmen wir an, wie wollen die "Speichergröße" der Zahl 2 und K ermitteln.
"2" ist festgelegt auf 2 Byte, daran soll sich nichts ändern. 2 Byte werden niemals geändert in diesem Fall.
Nun ist "K" zu klären, der Buchstabe "K" hat eine andere grafische Struktur, sprich eine andere Darstellung, sonst wäre "K" ja "2" und somit entstände keine Differenz zwischen den beiden.

Es geht um die grafische Größe OHNE Hintergrund, und ohne speziellen Bezug auf verschiedenste Speichertypen.

Ich gehe davon aus, dass "K" eine etwas Größer von der Grafik ist, und somit gegenüber den 2 Byte, größer sein muss.

@NordicStorm

Es ist etwas schwierig zu folgen, weil wir deinen technischen Hintergrund nicht kennen, wo man fürs Erklären also Ansetzen muß...

NordicStorm schrieb: Kein Font oder ähnliches.

Also kein Font.

NordicStorm schrieb:Nun ist "K" zu klären, der Buchstabe "K" hat eine andere grafische Struktur,

Also doch wieder Font. Der Font legt die grafische Struktur eines Zeichens fest. Ohne Font keine grafische Struktur.

Also von Anfang an: Alle Zeichen werden zunächst einmal im Speicher als Zahl codiert abgelegt. "2" hat den Code 50, "K" den Code 75. Dafür reicht ein Byte aus, man kann den Code aber natürlich auch in zwei Bytes ablegen, das eine Byte wird dann auf 0 gesetzt.

Codiert im Speicher nehmen die Zeichen also den gleichen Speicherplatz weg. Dafür liegt dann aber eben im Speicher auch keine "2" und "K", sondern nur die Zahlen 50 und 75.

Wenn man diese Zeichen nun darstellen möchte, muß man aus den Codes 50 und 75 kleine Grafiken machen, die eine "2" und ein "K" darstellen. Diese Konvertierung von Code zu Grafik macht der Font. Der legt fest, welche Pixel bei einem bestimmten Code an- und ausgeschaltet werden sollen.

Falls du bei den 2 Bytes an Grafikspeicher denkst: Bei 2 Byte hat man 16 Bit zur Verfügung. Bei 1 Bit pro Pixel (an oder aus) reicht das gerade mal für eine Zeichengröße von 4x4 Pixeln, da kriegt man kaum lesbare Zeichen drin unter (abgesehen davon würde man das in der Praxis auch nicht in zwei Bytes hineingepackt bekommen).

Wieviel Pixel die Darstellung von "2" und "K" nun verbrauchen, hängt vom verwendeten Font ab. Bei einem Fixed-Font wie Courier hat jedes Zeichen die gleiche Breite und Höhe, und verbraucht damit die gleiche Anzahl von Pixeln.

Bei einem Proportionalfont haben die Zeichen unterschiedliche Breiten. Da hängt es vom Font ab, wie breit die "2" und wie das "K" wird - die Höhe dürfte immer dieselbe sein. Mit der unterschiedlichen Breite schwankt dann eben auch der Speicherbedarf für das jeweilige Zeichen. Da jeder Font die Zeichen unterschiedlich darstellen kann, ist Aussage, wie groß der Speicherbedarf ist, einfach nicht möglich, sondern Font-abhängig.

NordicStorm schrieb:Es geht um die grafische Größe OHNE Hintergrund,

Jedes Zeichen wird in einen rechteckigen Block gezeichnet und hat deswegen nun einmal einen Hintergrund; entweder gehört ein Pixel zum Buchstaben, dann ist er eingeschaltet, oder er gehört nicht zum Buchstaben, damit zum Hintergrund und ist ausgeschaltet.

Ich nehme mal an, dir geht es nicht um die Anzahl der Pixel aus denen ein Zeichen besteht?

Ich hoffe, ich habe dein Problem irgendwie getroffen, mir ist das ganze wirklich weiterhin unverständlich...

Z.

@NordicStorm

NordicStorm schrieb:Es geht um die grafische Größe OHNE Hintergrund, und ohne speziellen Bezug auf verschiedenste Speichertypen.

Das kann man aber nicht so einfach beantworten. Eine Schriftart ist normalerweise kein vorberechnetes Pixelbild, sondern liegt als mathematische Beschreibung vor. Ich glaub im Fall von TrueType sind das Bezierkurven. Das hat den Vorteil, dass man die Schrift beliebig groß oder klein machen kann ohne Verlust an Qualität. Jetzt kann so eine Schrift allerdings nicht direkt angezeigt werden, weil Grafikkarte und Monitor ja mit Pixeln arbeiten. Das bedeutet, die mathematische Beschreibung der Schrift muss in eine Pixelgrafik umgewandelt werden. Und das geht je nach Hard- und Software unterschiedlich. Wie viele Pixel ein Zeichen nach der Rasterisierung hat, kommt also auf die verwendete Umgebung an.

Hier siehst du rechts, wie unterschiedlich das Resultat je nach Art der Rasterisierung werden kann:
Wikipedia: Font rasterization

NordicStorm schrieb:Ich formuliere es noch anders: Nehmen wir an, wie wollen die "Speichergröße" der Zahl 2 und K ermitteln.
"2" ist festgelegt auf 2 Byte, daran soll sich nichts ändern. 2 Byte werden niemals geändert in diesem Fall.
Nun ist "K" zu klären, der Buchstabe "K" hat eine andere grafische Struktur, sprich eine andere Darstellung, sonst wäre "K" ja "2" und somit entstände keine Differenz zwischen den beiden.

Selbst wenn du «2» auf eine gewisse Speichergröße festschreibst ändert das nichts daran, dass «K» die gleiche Speichergröße haben kann. Außerdem hat die Information, dass ein «K» im Speicher vorliegt absolut nichts mit der grafischen Darstellung zu tun.

Zeichen, egal welchen Fonts, haben eine feste Speichergrösse. Ein Ascii-Zeichen, ob es nun eine 2 oder ein K ist, ist immer ein Byte gross. Ein Byte kann 256 Zustände(0...255) annehmen, daher hat der Ascii-Satz 256 Zeichen. Heutzutage verwendet man natürlich nicht mehr Ascii, sondern z.B. Unicode. Da ist ein Zeichen 1-4 Byte gross. Da ein Speicherplatz alle Zeichen aufnehmen können muss, werden immer 4 Bytes reserviert. Macht aber nix, die Zeiten in denen man sich einen Kopp um einzelne Bytes machen musste sind längst vorbei. Darum geht es hier doch nicht, oder? Diese Byte-Fitzelei ist ein Hackerklischee aus den Achtzigern.

Die grafische Darstellung wird vom Speicher getrennt behandelt. Vielleicht variiert die Grösse des zur Darstellung einzelner Zeichen benötigten Speichers, intern nutzen aber alle Zeichen die selbe Grösse. Sonst müsste man für jedes zu speichernde Zeichen prüfen: Ist es eine 2? -> reserviere 2 Bytes. Ist es ein "K"? -> reserviere 3 Bytes. Katastrophe, würde die Laufzeit für jedes Programm, das Text darstellt, drastisch verlängern. Mit der aktuellen Methode geht's einfach: "Ich möchte ein Zeichen speichern" ->"Hmkay, hier haste 4 Byte".

@Dahergelaufen

Dahergelaufen schrieb:Die grafische Darstellung wird vom Speicher getrennt behandelt. Vielleicht variiert die Grösse des zur Darstellung einzelner Zeichen benötigten Speichers, intern nutzen aber alle Zeichen die selbe Grösse.

Wie erwähnt, das ist nur richtig, wenn die Darstellung in einem unkomprimierten Format und jeder Pixel explizit gespeichert wird.

@Quimbo

Verstehe ich nicht: Es werden doch überhaupt keine Pixel gespeichert, es sei denn der Text ist eine irgendwie geartete Grafik, oder? Ich muss zugeben, dass ich mich mit den moderneren Aspekten der Programmierung immer noch nicht so richtig auseinander gesetzt habe. Ich code einfach nicht genug.

Edit:

Lass dir mit der Antwort ruhig Zeit, als anständiger Viehbauer, der ich heute mal bin, gehe ich jetzt ins Betti. *gähn*

Dahergelaufen schrieb:Verstehe ich nicht: Es werden doch überhaupt keine Pixel gespeichert, es sei denn der Text ist eine irgendwie geartete Grafik, oder? Ich muss zugeben, dass ich mich mit den moderneren Aspekten der Programmierung immer noch nicht so richtig auseinander gesetzt habe.

Bevor ein Pixel angezeigt wird, muss er irgendwie in der Hardware gespeichert sein, z.B. im Framebuffer der Grafikkarte. Und der kann durchaus komprimieren, was bei mobilen Prozessoren garnicht so unüblich ist, um Bandbreite und damit Strom zu sparen.

@Quimbo

Quimbo schrieb:Wie erwähnt, das ist nur richtig, wenn die Darstellung in einem unkomprimierten Format und jeder Pixel explizit gespeichert wird.

Ich bin mir ziemlich sicher, daß jeder Font erst einmal in den Arbeitsspeicher gerendert wird, bevor er benutzt werden kann, und verbraucht damit Speicher. Also:

Auf der Platte liegt der Font in irgendeiner Form vor, z.B. komprimiert und/oder als Vektorbeschreibung.

Wenn nun ein Programm einen Buchstaben malen möchte, öffnet es den Font, und das Betriebssystem generiert aus den Font-Daten Pixel-Abbilder im Arbeitsspeicher, in Abhängigkeit von der gewünschten Zeichengröße.

Das Programm malt nun den gewünschten Buchstaben, indem die gerenderten Pixeldaten aus dem Arbeitsspeicher in den Framebuffer kopiert und angezeigt werden. Genauer gesagt wird das letztendlich nicht vom Programm, sondern vom Betriebssystem erledigt.

Jeden Buchstaben einzeln zu dekomprimieren oder aus den Vektordaten zu generieren wäre viel zu aufwendig.

Z.

zaeld schrieb: Genauer gesagt wird das letztendlich nicht vom Programm, sondern vom Betriebssystem erledigt.

Sagt ja auch niemand, dass man das manuell machen muss, aber das Betriebssystem ist im Endeffekt auch ein bestimmtest Programm und benutzt einen bestimmten Rasterizer, der das Ergebnis im Sinne der Fragestellung beeinflussen kann.

zaeld schrieb:Jeden Buchstaben einzeln zu dekomprimieren oder aus den Vektordaten zu generieren wäre viel zu aufwendig.

Das wird aber genau so gemacht, zumindest unter Windows. Einmalig pro Session, dann wird gecached. Die FreeType font engine z.B. kann dabei auch die Buchstaben im Cache komprimieren. Keine Ahnung ob Windows das auch macht. Ich würd's machen, wenn ich die Engine geschrieben hätte ;)

@Quimbo

Quimbo schrieb:Sagt ja auch niemand, dass man das manuell machen muss, aber das Betriebssystem ist im Endeffekt auch ein bestimmtest Programm

Klar, das wäre ja furchtbar, wenn jedes Programm sich noch ums Malen der Buchstaben kümmern müßte.

Quimbo schrieb:Das wird aber genau so gemacht, zumindest unter Windows.

Ich glaube, wir meinen dasselbe. Das Programm öffnet den Font, den es verwenden möchte, und das Betriebssystem malt erst einmal die ganzen Buchstaben vor, damit danach nur noch kopiert werden muß. In dem Satz, den du zitiert hast, fehlte wohl ein "immer wieder neu aus den Vektordaten generiert" oder so.

Z.

@zaeld
@Quimbo
@Dahergelaufen

@NordicStorm hat nirgends geschrieben, ob es ihm um Fonts, Bitmaps, Vektorgrafiken oder chars geht.

Ich denke, dass folgende Aussagen zeigen, dass der TE nicht verstanden hat, wie Speicher im Computer funktioniert:

NordicStorm schrieb am 09.10.2014:Die Frage ist nach wie vor ob "K" genauso groß sein kann wie "2", wenn "2" 2 Byte groß ist.
"K" hat eine andere Struktur, sieht anders aus, kann "K" dann auch genau 2 Byte groß sein?!

NordicStorm schrieb am 09.10.2014:"2" sagen wir 2 Byte und "K" dann evtl 2,039 Byte?

Ich frage mich, wie 0.312 Bit möglich sein sollen. :D Auch wenn es eine hypothetische Frage war, ist es doch etwas unlogisch.

Heizenberch schrieb:hat nirgends geschrieben, ob es ihm um Fonts, Bitmaps, Vektorgrafiken oder chars geht.

Hab ja geschrieben, dass das auf viele Faktoren ankommt. So einfach beantworten kann man das nicht.

Heizenberch schrieb:Ich frage mich, wie 0.312 Bit möglich sein sollen. :D Auch wenn es eine hypothetische Frage war, ist es doch etwas unlogisch.

Das mit den 2 Byte sollten wir wie gesagt vergessen.

@NordicStorm

Du solltest deine Frage präzisieren und die verwirrenden Vergleiche weglassen, keine hypothetischen Größen annehmen.

@Quimbo
Ah, OK. Im Grafikspeicher natürlich, aber beim gespeicherten Text, der ja in vielen verschiedenen Fonts dargestellt werden kann, wird die Speichergrösse konstant bleiben. Sollte das in der seither geführten Disku schon geklärt worden sein, sorry, hab verpennt und sollte in dieser Minute schon auf Arbeit sein. Wah! Zum Glück wohne ich direkt am Arbeitsplatz.