The signature of the ouputYourself method is (self, typesetter, line)
I'd question, with the rationale of dis-entangling concepts, why the typesetter is still needed at output time.
Normally, the typesetter's job ought to be finished then, as we are pushing completed (= fully typeset) content to the page...
Unless mistaken, in all cases, what we only need... is the frame, to keep track of cursor positions.
I couldn't find other use cases in the code base than typesetter.frame.direction (e.g. in boustrophedon), typesetter.frame:advancePageDirection or typesetter.frame:advanceWritingDirection, typesetter.frame:newLine()typesetter.frame:newLine(), typesetter.frame.state.cursorX and/or typesetter.frame.state.cursorY -- visibly, unless I missed something, it's always using the frame.
There's a reason why the typesetter was passed, as shown in #1981: at a much earlier stage, the frames were not here and the cursor tracking was done in the typesetter -- but that was in 2014...
So it would seem we now pass the typesetter to a method only needing the typesetter's frame, which does indeed sound logical...
Is this correct and should we proceed forward changing the signature and passing only the typesetter's frame?
(A compatibility shim should be straightforward, with a frame.frame field pointing to itself)
So here it is, from https://github.com/sile-typesetter/sile/pull/1981#issue-2115697365
The signature of the
ouputYourselfmethod is(self, typesetter, line)I'd question, with the rationale of dis-entangling concepts, why the typesetter is still needed at output time.
Normally, the typesetter's job ought to be finished then, as we are pushing completed (= fully typeset) content to the page...
Unless mistaken, in all cases, what we only need... is the frame, to keep track of cursor positions.
I couldn't find other use cases in the code base than
typesetter.frame.direction(e.g. in boustrophedon),typesetter.frame:advancePageDirectionortypesetter.frame:advanceWritingDirection,typesetter.frame:newLine()typesetter.frame:newLine(),typesetter.frame.state.cursorXand/ortypesetter.frame.state.cursorY-- visibly, unless I missed something, it's always using the frame.There's a reason why the typesetter was passed, as shown in #1981: at a much earlier stage, the frames were not here and the cursor tracking was done in the typesetter -- but that was in 2014...
So it would seem we now pass the typesetter to a method only needing the typesetter's frame, which does indeed sound logical...
Is this correct and should we proceed forward changing the signature and passing only the typesetter's frame? (A compatibility shim should be straightforward, with a
frame.framefield pointing to itself)