« first day (1 day earlier)    last day (15 days later) » 

David Carlisle
David Carlisle
10:21 PM
@AbstractDissonance @AbstractDissonance I have answered that in each of your question, I'm not how else I can say it. Page breaking is undertaken by the output routine which happens asynchronously with building up the main vertical list. In this case tex does a least cost optimisation on a whole paragraph to break the paragraph into lines, so until line 74 almost the end of the document everything is being build as one horizontal list.
@AbstractDissonance at the blank line in the source first the line breaker is invoked which makes a vertical list of lines, then the page breaker is invoked shipping out a number of pages, that is why in all these cases several pages are output from the same source line (the blank line in the file)
@AbstractDissonance You can add a comma on line 74 that will appear on page 4 but which affects the page break between page 1 and 2. That is why all the pages in these examples show as coming from the same source line.
 
AbstractDissonance
AbstractDissonance
11:18 PM
@DavidCarlisle I did not know it did it asynchronously, You never mention that or I did not read it. Obviously that makes a big different ;) It sucks for me in that it means I cannot do what I want easily and maybe impossible without modifying the engine itself ;/ I do not know why such simple things are so hard. There is a correspondence between where the source code is located and what it generates in the pdf. I am not looking for perfection but a way to cache
To automate the caching, rather than litter the source with caching macros, one must have some way to partition the code up in to chunks to test for modifications(since if one chances any character in the doc the whole doc changes but that doesn't mean that the whole doc has to be changed). But this requires certain capabilities that either tex/lualatex does not contain or no one knows how to do it.
 
David Carlisle
David Carlisle
@AbstractDissonance see above:-)
2 days ago, by egreg
@AbstractDissonance You're forgetting that TeX breaks pages asynchronously with paragraphs. A page break mostly happens when a paragraph has already entirely built in memory, so when the output routine is called, \inputlineno has already been set to the line number where the paragraph ended. Other programming languages don't typeset paragraphs and pages, so you're comparing apples and oranges.
@AbstractDissonance You really are mistaken about the correspondence, there is no reason why you can take part of the output of a program and associate it with a part of the input. Every page of the output potentially (and in the examples I posted with a single paragraph, actually) depends on the entire input document.
@AbstractDissonance It is not that tex misses some feature, it is that you are asking an insoluble problem: You are asking to take an omelette, slice it and specify which part of the egg each slice comes from.
 
David Carlisle
David Carlisle
11:43 PM
@DavidCarlisle I'm not sure if that would work. One can't completely unregister the code or it won't pick up anything after the macro is done doing it's business, must re-register or renable processing at some point some how, not sure if that is easily doable or not since one doesn't know what the macro has done. — AbstractDissonance 19 mins ago
@AbstractDissonance ^^ If your macro is inputting a file you have complete control and can certainly unregister the input buffer callback for just that file input. the callback is never called on macro text it is part of the file reader so called exactly once on each source line.
 
AbstractDissonance
AbstractDissonance
@DavidCarlisle We are going to just have to disagree. We are having a miscommunication on how we interpret things and we will never solve any problems as long as that is going on. My language has nothing/very little to do with TeX and you are using TeX to interpret how to understand the problem. I have proof that what I am doing works. The fact is that you really are not logically consistent. I also realize that you know more about TeX than me,
But I really think you are not allowing yourself to understand the problem as it is, which is a general problem and not dependent on tex(the solution may not be possible in side tex, but you do not present it like that... aka, your omlet example).
PROOF: I took your one paragraph example, the one you claim is a counter example to what I am saying... I compiled it, opened the pdf, double clicked on some random line and it takes me NOT to the first line but exactly to the line I clicked on. Hence if synctex can do it, it means that my logic is correct and you are not being logically consistent. So you need state things more accurate instead of making generalization that are provably wrong because that just makes things confusing
And we can never solve any problems as long as stuff like that happens. If you are claiming that TeX itself has no capabilities that allows it solve the problem I have describe, then that is one issue and I cannot necessarily argue with that because I am not a TeX expert, hence the reason I asked the question in the first place. BUT when you claim that the question itself is an impossibility then it tells me you do not know what you are talking about.
As a person that deals with TeX every day, you may be making assumptions that I am not making, but it is not my burden to find those assumptions and use them to be correct, it is yours, since you are the "expert". It is enough to say "TeX does not have any capabilities to do this because of it's design. Page generation is asynchronous to source line processing and TeX does not break blocks in to boundaries in any consistent way."
 

« first day (1 day earlier)    last day (15 days later) »