Breite einer Zeichenkette
Moderator: Moderatoren
Breite einer Zeichenkette
Hallo zusammen,
folgendes Problem:
Bei der Ausgabe fuer due Druckvorschau muessen Zeichenketten abgeschnitten werden, damit sie noch in die Tabelle passen. Eigentlich kein Problem. Mit
aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
kann die Breite der Zeichenkette ermittelt werden, den String kann man dann iterativ auf die zulaessige Breite verkuerzen. "GraQueryTextBox" rechnet bei mir aber falsch. Z.B. ist die Zeichenkette 741 Pts. breit, zulaessig waeren 750, bei der anschliesenden Ausgabe ist diese aber mindestestens 50 Pts. laenger und schreibt in die naechste Spalte. Das ganze variiert noch in Abhaengigkeit der Fonts und Fontgroessen.
Ist dieses Problem bekannt ? Mache ich einen Denkfehler ?
So definiere ich den Font:
::oFont := XbpFont ():new (::oPresSpace)
::oFont:familyName:= "Arial"
::oFont:nominalPointSize:= 9
::oFont:generic := .T.
::oFont:create()
das hier fuehrt zum selben Ergebnis:
::oFont := XbpFont():new():create( "10.Arial.normal" )
Gruss
Achim
folgendes Problem:
Bei der Ausgabe fuer due Druckvorschau muessen Zeichenketten abgeschnitten werden, damit sie noch in die Tabelle passen. Eigentlich kein Problem. Mit
aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
kann die Breite der Zeichenkette ermittelt werden, den String kann man dann iterativ auf die zulaessige Breite verkuerzen. "GraQueryTextBox" rechnet bei mir aber falsch. Z.B. ist die Zeichenkette 741 Pts. breit, zulaessig waeren 750, bei der anschliesenden Ausgabe ist diese aber mindestestens 50 Pts. laenger und schreibt in die naechste Spalte. Das ganze variiert noch in Abhaengigkeit der Fonts und Fontgroessen.
Ist dieses Problem bekannt ? Mache ich einen Denkfehler ?
So definiere ich den Font:
::oFont := XbpFont ():new (::oPresSpace)
::oFont:familyName:= "Arial"
::oFont:nominalPointSize:= 9
::oFont:generic := .T.
::oFont:create()
das hier fuehrt zum selben Ergebnis:
::oFont := XbpFont():new():create( "10.Arial.normal" )
Gruss
Achim
Re: Breite einer Zeichenkette
Hallo,
beim Durchforsten der Hilfe bin ich auf "GraPathClip" gestossen. Das ist genau das, was ich gesucht habe. Von daher hat sich das Problem erledigt. Das "GraQueryTextBox" falsch rechnet, ist aber trotz allem erstaunlich.
Gruss
Achim
beim Durchforsten der Hilfe bin ich auf "GraPathClip" gestossen. Das ist genau das, was ich gesucht habe. Von daher hat sich das Problem erledigt. Das "GraQueryTextBox" falsch rechnet, ist aber trotz allem erstaunlich.
Gruss
Achim
Re: Breite einer Zeichenkette
Hallo Achim
das wäre ja sehr übel wenn GraQueryTextBox falsch rechnen würde!
Da stimmt irgend etwas mit Deiner Vorgehensweise nicht.
Keine oder falsche Manifest-Datei mit Desktop-Darstellung <> 100%
oder was auch immer.
Re: Breite einer Zeichenkette
Hallo Roland,
es gibt so manches, was in Xbase nicht sauber laeuft. Meine Spoolerumgebung basiert auf dem "Preview" Beispiel von Xbase, das ich mir im Laufe der Jahre angepasst habe.
>Keine oder falsche Manifest-Datei mit Desktop-Darstellung <> 100%
was meinst Du damit ?
Aktuell mache ich das nun so:
GraPathBegin (::oViewPort:oPresSpace)
GraBox (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte})
GraPathEnd (::oViewPort:oPresSpace)
GraPathClip (::oViewPort:oPresSpace, .T.)
Das funktioniert pixelgenau. Wenn ich zwei Zeilen vorher "GraQueryTextBox ()" laufen lasse, liefert diese falsche Koordinaten.
Hier mal eine Quick+Dirty Loesung, die zwar nicht schoen ist, aber funktionieren sollte:
DO WHILE .T.
aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
*
IF aPoints [4, 1] - aPoints [1, 1] < nLimit
EXIT
ENDIF
*
cValue:= LEFT (cValue, LEN (cValue) - 1)
ENDDO
der String ist nach Durchlauf der Schleife auf eine Laenge < nLimit gekuerzt, bei der anschliessenden Ausgabe ist er aber groesser, als von GraQueryTextBox () vorhergesagt. Da alles andere pixelgenau funktioniert, kann meine Umgebung nicht voellig falsch sein.
Gruss
Achim
es gibt so manches, was in Xbase nicht sauber laeuft. Meine Spoolerumgebung basiert auf dem "Preview" Beispiel von Xbase, das ich mir im Laufe der Jahre angepasst habe.
>Keine oder falsche Manifest-Datei mit Desktop-Darstellung <> 100%
was meinst Du damit ?
Aktuell mache ich das nun so:
GraPathBegin (::oViewPort:oPresSpace)
GraBox (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte})
GraPathEnd (::oViewPort:oPresSpace)
GraPathClip (::oViewPort:oPresSpace, .T.)
Das funktioniert pixelgenau. Wenn ich zwei Zeilen vorher "GraQueryTextBox ()" laufen lasse, liefert diese falsche Koordinaten.
Hier mal eine Quick+Dirty Loesung, die zwar nicht schoen ist, aber funktionieren sollte:
DO WHILE .T.
aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
*
IF aPoints [4, 1] - aPoints [1, 1] < nLimit
EXIT
ENDIF
*
cValue:= LEFT (cValue, LEN (cValue) - 1)
ENDDO
der String ist nach Durchlauf der Schleife auf eine Laenge < nLimit gekuerzt, bei der anschliessenden Ausgabe ist er aber groesser, als von GraQueryTextBox () vorhergesagt. Da alles andere pixelgenau funktioniert, kann meine Umgebung nicht voellig falsch sein.
Gruss
Achim
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Breite einer Zeichenkette
Ironie ON
vor oder nach deinen Anpassungen
Ironie OFF
so wie es jetzt aussieht nimmst du deinen eigenen Grafischen Pfad, Ok.Statler hat geschrieben: Aktuell mache ich das nun so:Das funktioniert pixelgenau.Code: Alles auswählen
GraPathBegin (::oViewPort:oPresSpace) GraBox (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte}) GraPathEnd (::oViewPort:oPresSpace) GraPathClip (::oViewPort:oPresSpace, .T.)
hm ...Statler hat geschrieben:Wenn ich zwei Zeilen vorher "GraQueryTextBox ()" laufen lasse, liefert diese falsche Koordinaten.
zeigt doch bitte mal die 3 Zeile davor auch
ist dabei schon ein Segment geöffent mit
Code: Alles auswählen
nSegment := GraSegOpen( oPS )
ich würde schon gerne sehen wie/wo du jeweils den ::oFont setzt (wirst ja nicht nur mit Arial.9 arbeiten)
---
es gibt von Günter Beyes ein Demo / Thread "GraQueryTextBox vs. GetTextExtentPoint32"***
wenn du also "ausprobierst" ob noch etwas passt wäre die API Methode wesentlich schneller ... und genauer.
Xbpfont ist wie üblich "beschränkt" und ein Object ... und man bekommt kein Handle so einfach
*** viewtopic.php?f=12&t=5948&p=66896
in dem Demo kann man die Font Beschränkungen erkennen welche Möglichkeiten es gäbe
gruss by OHR
Jimmy
Jimmy
Re: Breite einer Zeichenkette
Hallo,
Hier die Ausgaberoutine. Ich habe mir eine Umgebung fuer Tabellendruck gebaut, in der Ich Zeilenweise adressesieren kann. Die Spalten werden ueber die ueblichen X-Koordinaten adressiert. Spalten werden durch sekrechte Linien getrennt. Mein Ziel war es, das Strings, die zwischen die Linien gedruckt werden, diese nicht ueberschreiben. Die Variable nLimit enthaelt den Abstand zwischen zwei Linien.
>ich würde schon gerne sehen wie/wo du jeweils den ::oFont setzt (wirst ja nicht nur mit Arial.9 arbeiten)
ich arbeite nur mit Areal.9. Das sind einfache Buchhaltungslisten, Optik interssiert da niemanden. Der Fond wir einmal zu Anfang gesetzt.
>ist dabei schon ein Segment geöffent mit
Ja, an einer anderen Stelle:
GraSegDrawMode (oPS, GRA_DM_RETAIN)
nSegment:= GraSegOpen (oPS)
Gruss
Hier die Ausgaberoutine. Ich habe mir eine Umgebung fuer Tabellendruck gebaut, in der Ich Zeilenweise adressesieren kann. Die Spalten werden ueber die ueblichen X-Koordinaten adressiert. Spalten werden durch sekrechte Linien getrennt. Mein Ziel war es, das Strings, die zwischen die Linien gedruckt werden, diese nicht ueberschreiben. Die Variable nLimit enthaelt den Abstand zwischen zwei Linien.
Code: Alles auswählen
METHOD Spooler:printFeld (nSpalte, nZeile, xFeld, nAlignment, nOffset, nLimit)
*
*******************************************************************
* Lokale Variablen *
*******************************************************************
*
LOCAL nX, nY, cValue, nFontmitte, aPoints,;
;
aPageSize:= ::oViewPort:aPageSize,;
aAttr:= ARRAY (GRA_AS_COUNT)
*
*******************************************************************
* Feld aufbereiten *
*******************************************************************
*
cValue:= xFeld
*
IF VALTYPE (xFeld) == "N"
cValue:= ALLTRIM (::getFeld (xFeld))
ENDIF
*
*IF ! EMPTY (nLimit)
* DO WHILE .T.
* aPoints:= GraQueryTextBox (::oViewPort:oPresSpace, cValue)
* *
* IF aPoints [4, 1] - aPoints [1, 1] < nLimit
* EXIT
* ENDIF
* *
* cValue:= LEFT (cValue, LEN (cValue) - 1)
* debugout (STR (nLimit, 4)+" " + STR (aPoints [4, 1] - aPoints [1, 1], 4))
* ENDDO
*ENDIF
*
*******************************************************************
* X-Koordinate (Spalte) aufbereiten *
*******************************************************************
*
nX:= ::nBorderLeft + nSpalte
*
IF nAlignment == kPrintAlignL
aAttr [GRA_AS_HORIZALIGN] := GRA_HALIGN_LEFT
ENDIF
*
IF nAlignment == kPrintAlignC
aAttr [GRA_AS_HORIZALIGN] := GRA_HALIGN_CENTER
ENDIF
*
IF nAlignment == kPrintAlignR
aAttr [GRA_AS_HORIZALIGN] := GRA_HALIGN_RIGHT
ENDIF
*
*******************************************************************
* Y-Koordinate (Zeile) aufbereiten *
*******************************************************************
*
nY:= 0
*
IF nOffset == kPrintUnten
nY:= ::nBorderFooter + (nZeile - 1) * ::nFontHoehe + INT (::nFontHoehe / 2)
ENDIF
*
IF nOffset == kPrintOben
nY:= aPageSize [2] - (::nBorderHeader + nZeile * ::nFontHoehe - INT (::nFontHoehe / 2))
ENDIF
*
IF nOffset == kPrintObenOffset
nY:= aPageSize [2] - (::nBorderHeader + ::nOffsetData + nZeile * ::nFontHoehe - INT (::nFontHoehe / 2))
ENDIF
*
*******************************************************************
* Text ausgeben *
*******************************************************************
*
aAttr [GRA_AS_VERTALIGN]:= GRA_VALIGN_TOP
nFontmitte:= INT (::oViewPort:oFont:height / 2)
*
* // Eventuell Begrenzung einrichten //
*
IF ! EMPTY (nLimit) .AND. nAlignment == kPrintAlignL
GraPathBegin (::oViewPort:oPresSpace)
GraBox (::oViewPort:oPresSpace, {nX, nY - nFontmitte}, {nX + nLimit, nY + nFontmitte})
GraPathEnd (::oViewPort:oPresSpace)
GraPathClip (::oViewPort:oPresSpace, .T.)
ENDIF
*
* // Zeichenkette ausgeben //
*
GraSetAttrString (::oViewPort:oPresSpace, aAttr )
GraStringAt (::oViewPort:oPresSpace, {nX, nY + nFontmitte}, cValue)
*
* // Eventuell Begrenzung wieder aufheben //
*
IF ! EMPTY (nLimit) .AND. nAlignment == kPrintAlignL
GraPathClip (::oViewPort:oPresSpace, .F.)
ENDIF
*
*******************************************************************
* Das war`s *
*******************************************************************
*
RETURN cValue
ich arbeite nur mit Areal.9. Das sind einfache Buchhaltungslisten, Optik interssiert da niemanden. Der Fond wir einmal zu Anfang gesetzt.
>ist dabei schon ein Segment geöffent mit
Ja, an einer anderen Stelle:
GraSegDrawMode (oPS, GRA_DM_RETAIN)
nSegment:= GraSegOpen (oPS)
Gruss
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: Breite einer Zeichenkette
Von oPS sehe ich aber nichts in Deiner Methode!
Wenn Du mit GraQueryTextBox() arbeitest, geht das so (und zwar ganz wunderbar):
Damit wird der Text in der Variable text an der Position 200,nY ausgegeben und dann vier Pixel tiefer mit einer Linie unterstrichen, die genauso lange ist, wie der Text.
Der :mode des PresentationSpace ist in meinem Fall auf XBPPS_MODE_HIGH_PRECISION gesetzt und die Einheiten auf GRA_PU_LOMETRIC
Viele Grüße,
Martin
Wenn Du mit GraQueryTextBox() arbeitest, geht das so (und zwar ganz wunderbar):
Code: Alles auswählen
GraStringAt( oPS, { 200, nY }, text )
nY -= 4
aTextBox := GraQueryTextBox( oPS, text )
GraLine( oPS, {200, nY}, { 200 + ( aTextBox[ 3, 1 ] - aTextBox[ 2, 1 ] ), nY} )
Der :mode des PresentationSpace ist in meinem Fall auf XBPPS_MODE_HIGH_PRECISION gesetzt und die Einheiten auf GRA_PU_LOMETRIC
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
Re: Breite einer Zeichenkette
Hallo,
>Von oPS sehe ich aber nichts in Deiner Methode!
heist bei mir: ::oViewPort:oPresSpace
>meinem Fall auf XBPPS_MODE_HIGH_PRECISION gesetzt und die Einheiten auf GRA_PU_LOMETRIC
verwende ich auch.
Gruss
>Von oPS sehe ich aber nichts in Deiner Methode!
heist bei mir: ::oViewPort:oPresSpace
>meinem Fall auf XBPPS_MODE_HIGH_PRECISION gesetzt und die Einheiten auf GRA_PU_LOMETRIC
verwende ich auch.
Gruss
- brandelh
- Foren-Moderator
- Beiträge: 15706
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 70 Mal
- Danksagung erhalten: 34 Mal
- Kontaktdaten:
Re: Breite einer Zeichenkette
In meiner Druckerklasse (HBPrinter) nutze ich in der Methode PrintMemo() diese Funktion für den Blocksatz, funktioniert einwandfrei,
wenn man alles richtig macht. In der Hilfe wird oft oPS weg gelassen und das geht natürlich nicht, die oPS muss gleich sein und von dem Drucker.
wenn man alles richtig macht. In der Hilfe wird oft oPS weg gelassen und das geht natürlich nicht, die oPS muss gleich sein und von dem Drucker.
Gruß
Hubert
Hubert
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Breite einer Zeichenkette
moin,
die malt zwar eine GraBox() "vorher" aber dann geht es an ein Segment welche mit
gemalt wird. in einem Segment "wirken" dadurch die GRA nun innerhalb eines "GRA-Path".
ein Segment ist aber nur temporär d.h. wenn müsste man den oPS von GraSegOpen(oPS)/GraSegClose(oPS) nehmen um GraSetFont(oPS) zu verwenden.
was Alaska da mit
macht ist IHMO nur verwirrend da man gewöhnlich nicht nur einen Font benutzt und es für GRA eben eigene Befehle gibt
es geht doch alles über die Method drawPage()
die malt zwar eine GraBox() "vorher" aber dann geht es an ein Segment welche mit
Code: Alles auswählen
GraSegDraw( ::presSpace(), ::segments[nPageNo] )
ein Segment ist aber nur temporär d.h. wenn müsste man den oPS von GraSegOpen(oPS)/GraSegClose(oPS) nehmen um GraSetFont(oPS) zu verwenden.
was Alaska da mit
Code: Alles auswählen
::oPresSpace:setFont( ::oFont )
gruss by OHR
Jimmy
Jimmy
Re: Breite einer Zeichenkette
Hallo zusammen,
ich habe noch ein paar Versuche gemacht. Das Problem haengt an der Schrift "X.Arial.normal" < 11 Punkte. Bei 11 bis ueber 20 Punkte rechtnet die Funktion einwandfrei, bei 9 und kleiner kommt nur noch Muell raus. Zum Vergleich habe ich noch die Api Funktion laufen lassen. Die Ergebnisse weichen um ein paar Pixel ab, sind aber tendenziell genaus so falsch.
Mit der Schrift "X.Euphemia.normal" sieht die Sache voellig anders aus, genaue Berechnungen bis unter 6 Punkte. Arial besteht aus mehreren Schriften, Euphemia gibt es nur einmal. Sonst ist mir kein Unterschuíed aufgefallen. Vectorschriften sind es beide.
Ich habe ein Win7 Umgebung.
Gruss
Achim
ich habe noch ein paar Versuche gemacht. Das Problem haengt an der Schrift "X.Arial.normal" < 11 Punkte. Bei 11 bis ueber 20 Punkte rechtnet die Funktion einwandfrei, bei 9 und kleiner kommt nur noch Muell raus. Zum Vergleich habe ich noch die Api Funktion laufen lassen. Die Ergebnisse weichen um ein paar Pixel ab, sind aber tendenziell genaus so falsch.
Code: Alles auswählen
FUNCTION GetTextExtents (oPs, cText)
LOCAL sSize := space(8)
LOCAL lOK := .F.
LOCAL hDC, nWidth, nHeight
STATIC tpl
IF tpl = NIL
tpl := DllPrepareCall("gdi32.dll", DLL_STDCALL, "GetTextExtentPoint32A" )
ENDIF
oPS:lockHDC ( 4, @hDC ) // param value 4: select font into device context
IF DllExecuteCall( tpl, hDC, cText, len( cText ), @sSize ) <> 0
lOK := .t.
nWidth := Bin2L( substr( sSize, 1, 4 ) )
nHeight := Bin2L( substr( sSize, 5, 4 ) )
debugout ({nWidth, nHeight})
ENDIF
RETURN lOK
Ich habe ein Win7 Umgebung.
Gruss
Achim
- Werner_Bayern
- Der Entwickler von "Deep Thought"
- Beiträge: 2128
- Registriert: Sa, 30. Jan 2010 22:58
- Wohnort: Niederbayern
- Hat sich bedankt: 30 Mal
- Danksagung erhalten: 75 Mal
Re: Breite einer Zeichenkette
Servus Achim,
die Erfahrung hab ich leider auch schon machen müssen, dass GraQueryTextBox() bei manchen Schriftarten in bestimmten Größen (!) falsche Ergebnisse bei der pixelgenauen Breitenberechnung liefert. Hab aktuell gerade nochmal mein Testprogramm von 2016 laufen lassen: Es werden aktuell alle Fonts korrekt berechnet. Aktuelles Windows 10, aktuelles Xbase++ (918).
Fonts werden fast mit jedem größerem Windows-Update geändert. Teste doch mal auf einem aktuellem Win10-System.
die Erfahrung hab ich leider auch schon machen müssen, dass GraQueryTextBox() bei manchen Schriftarten in bestimmten Größen (!) falsche Ergebnisse bei der pixelgenauen Breitenberechnung liefert. Hab aktuell gerade nochmal mein Testprogramm von 2016 laufen lassen: Es werden aktuell alle Fonts korrekt berechnet. Aktuelles Windows 10, aktuelles Xbase++ (918).
Fonts werden fast mit jedem größerem Windows-Update geändert. Teste doch mal auf einem aktuellem Win10-System.
es grüßt
Werner
<when the music is over, turn off the lights!>
Werner
<when the music is over, turn off the lights!>
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Breite einer Zeichenkette
hi Achim ,
---
in meiner Demo gehe ich nun den anderen Weg.
ich wähle aus einem (vorgegebenen) XbpFontDialog() einen Font.
auf einer XbpStatic lasse ich nun eine String anzeigen, Xbase++ like mit o:SetCaption()
das 2nd XbpStatic verwendet nun das Font-Handle welches neu erzeugt wurde und den selben String
das 3th XbpStatic arbeitet mit @ot4xb:_create_font_() wo ich mich an einer Font Grössen Umrechnung versucht habe
zu 2 & 3 muss ich noch sagen das ich @user32:DrawTextA() verwendet hab also per API
wie schon gesagt es ergeben sich Unterschiede aber eben schon beim Font der zur Berechnung genommen wird.
im Demo sehe ich den Unterschied und das wäre auch das Ergebnis einer Berechnung (für den Bildschirm in Pixel)
p.s. noch sprechen wir von "A"nsi aber mit Unicode "W" wird das mit den Fonts nicht einfacher ...
bislang gehst du davon aus das die Berechnung falsch seien aber was wenn die API "falsche/fehlende" Informationen vom Font bekommt ?
---
in meiner Demo gehe ich nun den anderen Weg.
ich wähle aus einem (vorgegebenen) XbpFontDialog() einen Font.
auf einer XbpStatic lasse ich nun eine String anzeigen, Xbase++ like mit o:SetCaption()
das 2nd XbpStatic verwendet nun das Font-Handle welches neu erzeugt wurde und den selben String
das 3th XbpStatic arbeitet mit @ot4xb:_create_font_() wo ich mich an einer Font Grössen Umrechnung versucht habe
zu 2 & 3 muss ich noch sagen das ich @user32:DrawTextA() verwendet hab also per API
wie schon gesagt es ergeben sich Unterschiede aber eben schon beim Font der zur Berechnung genommen wird.
im Demo sehe ich den Unterschied und das wäre auch das Ergebnis einer Berechnung (für den Bildschirm in Pixel)
p.s. noch sprechen wir von "A"nsi aber mit Unicode "W" wird das mit den Fonts nicht einfacher ...
gruss by OHR
Jimmy
Jimmy
Re: Breite einer Zeichenkette
Hallo,
>bislang gehst du davon aus das die Berechnung falsch seien aber was wenn die API "falsche/fehlende" Informationen vom Font bekommt ?
Ob jetzt die Api falsch rechnet oder der Font falsche Daten liefert ist erstmal uninteressant, das gelieferte Ergeniss ist unbrauchbar, warum auch immmer.
Zur genauen Analyse koennte man einen Text in eine berechnete Box drucken, und schauen, ob das passt; mit verschiedenen Fonts und verschiedenen Groessen.
Gruss
Achim
>bislang gehst du davon aus das die Berechnung falsch seien aber was wenn die API "falsche/fehlende" Informationen vom Font bekommt ?
Ob jetzt die Api falsch rechnet oder der Font falsche Daten liefert ist erstmal uninteressant, das gelieferte Ergeniss ist unbrauchbar, warum auch immmer.
Zur genauen Analyse koennte man einen Text in eine berechnete Box drucken, und schauen, ob das passt; mit verschiedenen Fonts und verschiedenen Groessen.
Gruss
Achim
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Breite einer Zeichenkette
NEIN denn anscheint nimmst du ja einen XbpFont / Grösse wo es NICHT passt.
wenn ich einen Font per API aufbaue mit ot4xb passt es IMMER mit den API Functionen
da kann ich jede beliebige Grösse wählen und es wird nicht "auf-/ab-gerundet" auf die nächste Point Grösse
Demo 2.) nimmt ja den XbpFont und wandelt es um. je nach gewählten Font bleibt 1.) und 2.) im mittleren Bereich gleich. unter 10 Point ist der XbpFont "zu gross" während er > 20 Point meistens "zu klein" ist.
die API rechnen richtig und wenn Xbase++ uns einen richtigen Font, mit allen Optionen, liefern würde hätten wir auch < 10 und > 20 Point keine Problem mit TTF Font.
p.s. bist du sicher das es der richtige Presspace ist ?
Code: Alles auswählen
METHOD XbpPreview:drawPage( nPageNo )
// das ist auf dem XbpPressspace()
GraBox( ::oPresSpace, {0,0}, ::aPageSize, GRA_FILL )
// und das ist ein Micro-Presspace
GraSegDraw( ::presSpace(), ::segments[nPageNo] )
gruss by OHR
Jimmy
Jimmy
Re: Breite einer Zeichenkette
Hallo,
erstmal gehe ich davon aus, das ich die von Xbase verwendeten Funktionen auch verwenden kann. In der Hilfe steht nichts bezueglich der Problematik mit den Fonts. Das man hier mit "dirty Hacks" hantieren muss, um eine laeppische Zeichenkette sauber auszudrucken, finde ich schon erstaunlich.
Meiner Meinung nach liegt ein Fehler in Xbase vor. Ich verwende Xbase Fonts in einer Xbase Umgebung mit Xbase Funktionen. Manchmal klappt es, manchmal nicht und man kann nicht mal sagen, woran es so genau liegt.
Mein Spooler basiert auf dem Xbase Preview Beispiel, Vorschau und Druck funktionieren seit Jahren einwandfrei, dort liegt kein Problem vor. User Werner hat das Problem ja ebenfalls bestaetigt.
Mit der Lib ot4xb ist das so eine Sache. Ich verwende die bereits fuer die Mail Umgebung (mapi). Kritische Teile einer Applikation, und der Druck gehoert dazu, nach otxb auzulagern ist ein gewisses Risiko. Was ist, wen Pablo irgenwann keinen Bock mehr hat und die Sache unter Xbase 3.0 nicht mehr laeuft ? Meine Philosphie ist, moeglichst nahe am Standard zu bleiben und Probleme mit z.B. neuen Betriebssysthemen durch Kauf eines aktuellen Compilers zu loesen.
Wegen Win10 bin ich auf Xbase 2.0 umgestiegen. Halber Tag Arbeit und meine Hauptapplikation lief wieder. Wenn dann noch irgendwelche externen Libs Aerger machen, kann das in Arbeit ausarten.
Bei der Sache mit den Fonts hat man aber anscheinend keine Wahl. Wenn Wortumbrueche oder pixelgenaues Unterstreichen gefragt ist, muss man den Font wohl via Api bzw. ot4xb erzeugen.
Nochmal besten Dank fuer die Hinweise auf die externen Loesungen.
Gruss
Achim
erstmal gehe ich davon aus, das ich die von Xbase verwendeten Funktionen auch verwenden kann. In der Hilfe steht nichts bezueglich der Problematik mit den Fonts. Das man hier mit "dirty Hacks" hantieren muss, um eine laeppische Zeichenkette sauber auszudrucken, finde ich schon erstaunlich.
Meiner Meinung nach liegt ein Fehler in Xbase vor. Ich verwende Xbase Fonts in einer Xbase Umgebung mit Xbase Funktionen. Manchmal klappt es, manchmal nicht und man kann nicht mal sagen, woran es so genau liegt.
Mein Spooler basiert auf dem Xbase Preview Beispiel, Vorschau und Druck funktionieren seit Jahren einwandfrei, dort liegt kein Problem vor. User Werner hat das Problem ja ebenfalls bestaetigt.
Mit der Lib ot4xb ist das so eine Sache. Ich verwende die bereits fuer die Mail Umgebung (mapi). Kritische Teile einer Applikation, und der Druck gehoert dazu, nach otxb auzulagern ist ein gewisses Risiko. Was ist, wen Pablo irgenwann keinen Bock mehr hat und die Sache unter Xbase 3.0 nicht mehr laeuft ? Meine Philosphie ist, moeglichst nahe am Standard zu bleiben und Probleme mit z.B. neuen Betriebssysthemen durch Kauf eines aktuellen Compilers zu loesen.
Wegen Win10 bin ich auf Xbase 2.0 umgestiegen. Halber Tag Arbeit und meine Hauptapplikation lief wieder. Wenn dann noch irgendwelche externen Libs Aerger machen, kann das in Arbeit ausarten.
Bei der Sache mit den Fonts hat man aber anscheinend keine Wahl. Wenn Wortumbrueche oder pixelgenaues Unterstreichen gefragt ist, muss man den Font wohl via Api bzw. ot4xb erzeugen.
Nochmal besten Dank fuer die Hinweise auf die externen Loesungen.
Gruss
Achim
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Breite einer Zeichenkette
Achim,
du bist ja nicht der einzigste der solche Function benutzt ...
auch wir anderen hätten es ja über die Jahr bemerken müssen und es gibt keine PDR dazu
---
wenn man etwas in einen vorhandenen Code einbaut und es nicht so funktioniert wie erwartet dann schreibe ich ein Demo. wenn bei einem 3-Zeiler auch wieder "falsche" Ergebnisse raus kommen dann hat man was für Alaska gefunden.
---
Das im Help File vieles nicht steht ist doch klar wenn Xbase++ die Fähigkeiten nicht bereit stellt.
das war ja auch einer der Gründe warum ich eigene native Controls mache da ich dort alle Fähigkeiten ausnutzen kann.
wenn jemand nur den XbpFont kennt und im Bereich von 10 - 20 Points arbeitet wird also gar nichts bemerken ob es 1 Pixel/Twips daneben liegt.
da du nicht von paar Pixel/Twips spricht sondern 2stellige Unterschiede feststellst vermute ich das es etwas anderes sein muss ...
---
ich gehe noch mal ein Schritt weiter ... nicht alles was Xbase++ uns anbietet existiert in Windows
ein Presspace kennt Windows NICHT. Windows kennt Device (Gerät) und Device Contexts (DC) in den ich "male"
unter Xbase++ kann ich ein XbpPresspace() mit einem Device verknüpfen was mit einem Micro-Presspace NICHT geht
deshalb auch meine mehrfach gestellte Frage ob jemand durchschaut warum Alaska beide im Preview Sample verwendet werden
wie Xbase++ basiert alles auf Windows API und ot4xb stellt in der Richtung offensichtlich mehr bereit als Xbase++
p.s.
bis die v3.x raus kommt könnte das uns bekannte Windows verschwunden sein. ob dann 32bit Apps noch voll unterstützt werden wird sich dann zeigen. schon heute bekommt man kaum mehr ein Mainboard mit 32bit UEFI um ein 32bit OS zu installieren und M$ ist ja am "ausmisten" der CORE Version die dann auch auf ARM CPU (mit 32bit Emulation)
läuft.
du bist ja nicht der einzigste der solche Function benutzt ...
auch wir anderen hätten es ja über die Jahr bemerken müssen und es gibt keine PDR dazu
zunächst mal sagtest du doch das du es angepasst hättest, also kann das KEINER von uns sagen was deine Version macht.
---
wenn man etwas in einen vorhandenen Code einbaut und es nicht so funktioniert wie erwartet dann schreibe ich ein Demo. wenn bei einem 3-Zeiler auch wieder "falsche" Ergebnisse raus kommen dann hat man was für Alaska gefunden.
---
Das im Help File vieles nicht steht ist doch klar wenn Xbase++ die Fähigkeiten nicht bereit stellt.
das war ja auch einer der Gründe warum ich eigene native Controls mache da ich dort alle Fähigkeiten ausnutzen kann.
wenn jemand nur den XbpFont kennt und im Bereich von 10 - 20 Points arbeitet wird also gar nichts bemerken ob es 1 Pixel/Twips daneben liegt.
da du nicht von paar Pixel/Twips spricht sondern 2stellige Unterschiede feststellst vermute ich das es etwas anderes sein muss ...
---
ich gehe noch mal ein Schritt weiter ... nicht alles was Xbase++ uns anbietet existiert in Windows
ein Presspace kennt Windows NICHT. Windows kennt Device (Gerät) und Device Contexts (DC) in den ich "male"
unter Xbase++ kann ich ein XbpPresspace() mit einem Device verknüpfen was mit einem Micro-Presspace NICHT geht
deshalb auch meine mehrfach gestellte Frage ob jemand durchschaut warum Alaska beide im Preview Sample verwendet werden
ot4xb ist Open Source d.h. du kannst Änderungen selbst vornehmen.Statler hat geschrieben:Was ist, wen Pablo irgenwann keinen Bock mehr hat und die Sache unter Xbase 3.0 nicht mehr laeuft ?
wie Xbase++ basiert alles auf Windows API und ot4xb stellt in der Richtung offensichtlich mehr bereit als Xbase++
p.s.
bis die v3.x raus kommt könnte das uns bekannte Windows verschwunden sein. ob dann 32bit Apps noch voll unterstützt werden wird sich dann zeigen. schon heute bekommt man kaum mehr ein Mainboard mit 32bit UEFI um ein 32bit OS zu installieren und M$ ist ja am "ausmisten" der CORE Version die dann auch auf ARM CPU (mit 32bit Emulation)
läuft.
gruss by OHR
Jimmy
Jimmy
Re: Breite einer Zeichenkette
Hallo zusammen,
das Problem ist gefunden.
2009: www.xbaseforum.de/viewtopic.php?f=23&t=3805&start=50
Das Preview Beispiel hat wohl einen kleinen Bug. Am Ende der Create Methode sollte folgendes stehen, danach wird richtig gerechnet. Die Reihenfolge spielt anscheinend eine Rolle.
// Presentation Space mit Window Device Context verknuepfen
::oPresSpace:configure (::oView:drawingArea:winDevice ())
::oPresSpace:setFont( ::oFont )
::oPresSpace:setAttrArea( ::aAreaAttr )
::oPresSpace:setAttrString( ::aCharAttr )
Es funktioniert nun mit native Xbase ohne irgendwelche API-Zugriffe. Dieser Bug betrifft anscheinend nur die Groessenberechnung, die eigentliche Ausgabe ist unveraendert.
Gruss
das Problem ist gefunden.
2009: www.xbaseforum.de/viewtopic.php?f=23&t=3805&start=50
Das Preview Beispiel hat wohl einen kleinen Bug. Am Ende der Create Methode sollte folgendes stehen, danach wird richtig gerechnet. Die Reihenfolge spielt anscheinend eine Rolle.
// Presentation Space mit Window Device Context verknuepfen
::oPresSpace:configure (::oView:drawingArea:winDevice ())
::oPresSpace:setFont( ::oFont )
::oPresSpace:setAttrArea( ::aAreaAttr )
::oPresSpace:setAttrString( ::aCharAttr )
Es funktioniert nun mit native Xbase ohne irgendwelche API-Zugriffe. Dieser Bug betrifft anscheinend nur die Groessenberechnung, die eigentliche Ausgabe ist unveraendert.
Gruss
- Martin Altmann
- Foren-Administrator
- Beiträge: 16555
- Registriert: Fr, 23. Sep 2005 4:58
- Wohnort: Berlin
- Hat sich bedankt: 115 Mal
- Danksagung erhalten: 48 Mal
- Kontaktdaten:
Re: Breite einer Zeichenkette
Dann ist klar, dass ich Dein Problem nicht nachvollziehen konnte. Ist schon zu lange her.
Viele Grüße,
Martin
Viele Grüße,
Martin
Webseite mit XB2.NET und ausschließlich statischem Content in Form von HTML-Dateien: https://www.altem.de/
Webseite mit XB2.NET und ausschließlich dynamischem Content in Form von in-memory-HTML: https://meldungen.altem.de/
Mitglied der XUG Osnabrück
Vorsitzender des Deutschsprachige Xbase-Entwickler e. V.
- AUGE_OHR
- Marvin
- Beiträge: 12913
- Registriert: Do, 16. Mär 2006 7:55
- Wohnort: Hamburg
- Hat sich bedankt: 19 Mal
- Danksagung erhalten: 46 Mal
Re: Breite einer Zeichenkette
klar das dass Demo dann bei mir läuft da ich es vor 9 Jahren geändert hatteStatler hat geschrieben: ↑Do, 17. Mai 2018 9:462009: www.xbaseforum.de/viewtopic.php?f=23&t=3805&start=50
API heisst nicht nur irgendwelche DLL Calls sondern das Verständniss von Windows was Grundlage von Xbase++ ist.Statler hat geschrieben:Es funktioniert nun mit native Xbase ohne irgendwelche API-Zugriffe.
gruss by OHR
Jimmy
Jimmy