Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also .
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
3
contributors
Commits on Feb 21, 2018
This way it always applies to anything processed by l3color.
Commits on Feb 22, 2018
Useful for Hobby paths, and in pgf done by simply setting \pgf@x/\pgf@y directly ...
These files all get auto-edited at each release.
The color part is omitted until we get to arrow support ...
Internal for the present
Commits on Feb 23, 2018
I suspect there is more to do here!
These might look strangely familiar ... Hopefully I've got the width about right now.
As close as possible to the pgf ones on the same functions.
Commits on Feb 24, 2018
This is consistent with pgf, and is more visually attractive when the grid is not an integer step size.
The lines now pass through the right places!
Mainly as we'd need the demo env twice
Commits on Feb 25, 2018
For floating point numbers I had decided that +0 and -0 are false and anything else is true. Consistent with this, tuples are always true.
As things are now quite stable, we can expect individual.
…see #438) The loop had been added to support situations where multiple floating point numbers were given to this operator. Tuples now show up differently.
This remaining problem only showed up if the argument of \fp_compare:nTF evaluates to a tuple, which does not happen for the supported syntax operand_1 relation_1 operand_2 etc.
Commits on Feb 26, 2018
This is not really a point/vector, just two values that are convenient to pass through the same mech!
The same ideas as in pgf, so the same limitation if the path is short ...
These may come back but need clear use cases.
Don't actually have text support just yet!
Probably for the type of path where this applies, l3tl-build is overkill.
Avoid any issues further down the line.
Some of this might not quite be true just yet!
This is needed in package mode: in format mode this will presumable be set from the get-go.
Commits on Feb 27, 2018
This is different to pgf: I suspect they do it for performance.
The name here could be \draw_path_scope_begin: - that might make sense but other types of scope don't have a 'family' of commands to sit within. Need to see how this looks in the wider scheme.
No change in functionality: purely making the code clearer (and using our own tools!).
Commits on Feb 28, 2018
This didn't show up in the kernel, but we were never restoring the stack in l3color!
... at least until we know why they are required!
This will avoid some interaction issues. Further check-ins required for full function here.
Follows from e1d5ff5.
Commits on Mar 02, 2018
This pulls together 'normal' and 'drawing' color: the latter is still documented separately as the stroke/fill split really only makes sense there. It's not possible to use the stack for fill color other than in pdfTeX/LuaTeX, as the other stacks don't cover general graphics isntructions. At present, the dvisvgm set up is untested: a lot of that code though likely needs further work.
Even at the driver layer this is more-or-less a given.
This longer name doesn't really help.
I have a feeling this makes more sense!
Neeed for the "ps::[begin]"/"ps::[end]" lines.
This will fit better with some internals, but also the fact that the two areas are separate.
At present this leaves the box stuff likely broken, but more work is needed there anyway. Note that the dvisvgm stuff is probably in need of heavy revision for both this and boxes. (Or perhaps not: SVG output is *very* different from everything else, so needs separate testing!)
Commits on Mar 03, 2018
The CTM is 'backward' compared withwat one might expect ...
In contrast to pgf, we want to do everything using driver-level specials rather than raw PostScript/PDF. That means that the interfaces need to be adjusted to avoid using translations at the driver level: these have to be done in TeX. There are various corrections to the driver code here. At present, the SVG path may be completely out-of-line. Note that some skews seem to mislead dvips/ps2pdf, resulting in entire pages rotating. That does not seem to be due to 'leaking' rotations, and is therefore likely down to some auto-detection somewhere.
This shows up with hyper-links.
Commits on Mar 04, 2018
This is the pgf way and will allow us to avoid needing lots of box/coffin functions.
We'll come back to a better interface shortly!
At present, this does not include an extra shift: one might emulate \pgftext by using a scoped pair of shifts.
As the bounding box is not right: likely better to stick to the pgf-like approach
This time actually dealing with the bounding box correctly (at least for non-rotated coffins). Question: do we want to support coffins rotated at the 'standard' level, or should this be left to drawing matrix work?
Also making the scope tests produce something useful.
The approach doesn't really offer anything for dvips: rotation/scaling there is still raw PostScript.
This one is tricky: there are a pair of specials, so we can't use it for setting the CTM directly. Thus this can only be used where we know exactly when a transformation ends.
Commits on Mar 05, 2018
This got missed before as l3build was forcing the epoch on typesetting: we now get an l3doc error.
We said we'd remove them: should really follow through.
l3kernel and l3experimental only.
Showing you all comments on commits in this comparison.
This comment has been minimized.
This comment has been minimized.
|
\draw_transform_shiftonly: or a variant thereof perhaps ? |
This comment has been minimized.
This comment has been minimized.
|
That's (I think) already covered by |
This comment has been minimized.
This comment has been minimized.
|
using texlua build.lua doc makes this "é" look "Ãľ". Encoding problem ? Locally I compile with luatex, but I don't know what your build system uses by default (I just built the needed deps with texlua build.lua install on the root, then texlua build.lua doc in l3draw). |
This comment has been minimized.
This comment has been minimized.
|
Wrong command in usage example |
There are no files selected for viewing