@federicomena I couldn't remember where the limit came from but I remembered that it was 16-bit. I guess it makes sense that pixman would have that limit considering its origins from inside xserver.
@federicomena Okay, yes, 2.45.5 gives me `(rsvg-convert:4177): librsvg-WARNING ...` followed by `Could not render file /tmp/big.svg`, so this is not an issue in current releases. 👍
@federicomena I ran into issues that I don't understand and that are probably NixOS-specific when trying to build from git master, but 2.45.5 is building now.
@federicomena I'm assuming the key issue is `<svg width="161953pt" height="134875pt" viewBox="0.00 0.00 161953.00 134875.00">`, yeah. I was about to test an SVG with just that root element.
@federicomena BTW I was simultaneously delighted and sad to get a Rust panic from rsvg-convert a couple days ago. Super cool to have evidence that it's Rust under the hood, but that wasn't the kind of evidence I wanted. 😅 (I tried to render an SVG with dimensions larger than cairo could handle. Turns out a lot of software breaks on images of that size, not just rsvg/cairo, so, this panic is hardly even a bug?)
@er1n haha, I'm not surprised. our research said we could make the problem go away for $25k, which is why we spent years building our own stuff instead 😅
Andrew Greenberg, of PSAS, did do a position fix implementation for his master's thesis, but that was for a chip that had 12 channels of GPS correlators in silicon. So I always hoped we eventually mash our software correlators together with his stuff, but eh.
also we really wanted to build a GPS-aided IMU, which would be quite different...
@er1n yes, that's true, neither my C implementation nor the subsequent capstone team's Python version actually got as far as position fixes. I keep meaning to come back to it with a Rust version, but I only got as far as submitting this iterator adapter for feedback loops to the rust-itertools maintainer: https://docs.rs/itertools-wild/0.1.1/itertools_wild/special/fn.feedback.html
@er1n I always wondered how long they were going to keep the open source thing going, but I'm still disappointed with them anyway.
But you could build a copy of our board instead! 😉 In hindsight, I should have picked a higher sample rate, and also it turns out that saving the generated Ethernet packets to flash without dropping any is trickier than I'd like. Overall I think it's a good board, though.
@er1n I assume so, but as long as you have the source code for the position fix bits, it's really difficult to make it difficult to remove those limits 🤔
@er1n sort of? depends on your size/weight/power/$/time budgets.
if you have a decent SDR receiver that can listen at 1575.42MHz with at least a few MHz bandwidth, there are open source implementations like https://github.com/gnss-sdr/gnss-sdr that worked in my experiments. we've written our own several times, too: https://github.com/psas/gps