Axx: Umrechnung von Schriftgröße in Twips ?
Thomas Krenn
Ich erstelle in einem Report mit der Funktion CreateReportControl(,,,) ein
Textfeld.
1. Da ich die Eigenschaften CanGrow und CanShrink wegen des Etikettendrucks
nicht verwenden kann, benötige ich für die Paramterangabe "Höhe" einen auf
die
Schrifthöhe in Punkten bezogenen Twips-Wert;
Beispiel: Arial 10 Pkt ==> ?? Twips
2. Ist die Umrechnung Auflösungsabhängig ?
Besten dank im voraus für Eure Hilfe.
Thomas
Johann Pumhösl
Thomas Krenn schrieb in Nachricht <94355059...@news.vbs.at>...
>Hi,
>
>Ich erstelle in einem Report mit der Funktion CreateReportControl(,,,) ein
>Textfeld.
>
>1. Da ich die Eigenschaften CanGrow und CanShrink wegen des Etikettendrucks
>nicht verwenden kann, benötige ich für die Paramterangabe "Höhe" einen auf
>die
>Schrifthöhe in Punkten bezogenen Twips-Wert;
>
>Beispiel: Arial 10 Pkt ==> ?? Twips
>
1 Twip = 1/20 Pkt => Arial 10 Pkt = 20 Twips + (ext.Leading der Schrift ca.
34%)
Wenn also dein Font die Schriftgröße 10 Punkte hat kannst du die Einstellung
näherungsweise so vornehmen:
DeinTextControl.Height = nPointSize * 20 * 1.34
Mit dieser Höhe werden auch die Ä's und Ü's bzw. die g's korrekt ausgegeben.
>
>2. Ist die Umrechnung Auflösungsabhängig ?
>
Meines wissens nicht, außer du hast vielleicht deinen Bericht auf eine
andere Skalierung eingestellt (punkt, pixel, twips...) siehe
AccessOnlIneHilfe bzw. Me.Scale und F1
>Besten dank im voraus für Eure Hilfe.
>
>Thomas
>
>
jp
Andreas Maurer
<pumhoes...@computerhaus.at> wrote:
>>2. Ist die Umrechnung Auflösungsabhängig ?
>>
>
>
>Meines wissens nicht, außer du hast vielleicht deinen Bericht auf eine
>andere Skalierung eingestellt (punkt, pixel, twips...) siehe
>AccessOnlIneHilfe bzw. Me.Scale und F1
Doch. Bei kleinen Schriftarten ist beispielsweise TwipsPerPixel 15,
bei großen 12.
Bye
Andreas
Kurt Grof
>
> Hi,
>
> Ich erstelle in einem Report mit der Funktion
> CreateReportControl(,,,) ein Textfeld.
>
> 1. Da ich die Eigenschaften CanGrow und CanShrink wegen des
> Etikettendrucks nicht verwenden kann
Wieso kannst Du wegen des Etikettendrucks CanGrow und
CanShrink *des Steuerelements* nicht verwenden ?
Dass Du die des (vermutlich Detail-) Bereichs nicht verwenden
willst leuchtet mir sofort ein, aber gerade das CanShrink
wird von den meisten AnwenderInnen hier bei uns ausdrücklich
gewünscht, weil es anscheinend eine DIN-Norm oder sonst eine
offizielle Empfehlung gibt, keine leeren Zeilen in der
Anschrift zu haben, und eben mit CanShrink beim Steuerelement
lassen sich solche vermeiden.
Gf.
Thomas Krenn
>Thomas Krenn schrieb:
>>
>> 1. Da ich die Eigenschaften CanGrow und CanShrink wegen des
>> Etikettendrucks nicht verwenden kann
>
>Wieso kannst Du wegen des Etikettendrucks CanGrow und
>CanShrink *des Steuerelements* nicht verwenden ?
>
Das Etikett soll eingerahmt sein. Und IMO nach Plazierung eines Rahmens auf
das Etikett wirkt CanShrink nicht so wie vermutet.
Würde der Rahmen nicht auf das Etikett müssen, ist CanShrink natürlich
anwendbar um Leerzeilen zu vermeiden.
>
>Gf.
tnx Thomas
Kurt Grof
>
> Kurt Grof schrieb in Nachricht <383E53EA...@sbl.co.at>...
> >Thomas Krenn schrieb:
> >>
> >> 1. Da ich die Eigenschaften CanGrow und CanShrink wegen des
> >> Etikettendrucks nicht verwenden kann
> >
> >Wieso kannst Du wegen des Etikettendrucks CanGrow und
> >CanShrink *des Steuerelements* nicht verwenden ?
> >
>
> Das Etikett soll eingerahmt sein. Und IMO nach Plazierung
> eines Rahmens auf das Etikett wirkt CanShrink nicht so wie
> vermutet.
IME (Experience) ist das leider so (und natürlich beschränkt
sich das dann nicht auf den Etikettendruck). Aber selbst
dann würde ich (reine Geschmackssache latürnich) lieber
mit einem Steuerelementinhalt wie
[Feld1] & IIf([Feld1] > " " And [Feld2] > " ";vbCrLf;"") & [Feld2] ...
arbeiten, als mich um Twips und vor allem Fontgrössen bei
Proportionalzeichensätzen kümmern zu müssen. Da hätte ich
viel zu viel Angst, dass das beim nächsten Druckertreiber
alles schon wieder ganz anders aussieht etc.
Gf.