I assume it primarily affects all functions of the version of VectorLib used here under WindowsOS.
Under Linux and Mac the error does not occur.
There is a shift of the output coordinates, which cannot be calculated with a workaround.
For pixel accurate outputs this is very bad.
I think it is the same bug as in this thread:
https://www.purebasic.fr/english/viewto ... =4&t=77019
But here the problem is now very concise and easy to make visible without having to analyze many postings which are first based on assumptions and only later become more and more concrete.
Therefore I kindly ask for your understanding.
The bug was probably not recognized by users for years, because usually very difficult to establish a connection between cause and effect.
The text lines themselves also shift, so about 1 pixel every three lines.
When DPI aware is used at high scales, it is in fact no longer possible to calculate a reasonably suitable offset with a workaround.
Code: Select all
window_ID=OpenWindow(#PB_Any, 0, 0, 600, 650, "", #PB_Window_ScreenCentered|#PB_Window_SystemMenu)
canvas_ID=CanvasGadget(#PB_Any, 0, 0, WindowWidth(window_ID), WindowHeight(window_ID))
font_ID=LoadFont(#PB_Any, "", 15+Bool(#PB_Compiler_OS=#PB_OS_Windows)) ; For better compare with Linux - Mac not adapted here
For i=1 To 25 : text$+LSet ("X", 30 ,"X") +#LF$ : Next i
StartVectorDrawing(CanvasVectorOutput(canvas_ID))
VectorFont(FontID(font_ID))
For i=1 To 25
VectorSourceColor($FF000000|#Red)
AddPathBox(0, ii, 500, 1)
; AddPathBox(0, ii+i, 500, 1) ; Workaround, but still shifts, with DPI aware and high scaling not usable - The correction must be approx. 1 pixel every three lines.
ii+VectorTextHeight("X")
StrokePath(1)
VectorSourceColor($FF000000|#Black)
DrawVectorParagraph(text$, WindowWidth(window_ID), WindowHeight(window_ID))
Next i
StopVectorDrawing()
Repeat : Until WaitWindowEvent()=#PB_Event_CloseWindow