Open kmdurand opened 9 years ago
kmdurand
commented
9 years ago I think the easiest way to fix this up is to just prevent the viewer from predicting which "even" commands should be "move" commands, and then to re-export all of the old 2014 shows for the server so that they no longer rely on that feature of the viewer.
brandonchinn178
commented
9 years ago I think it's fine to keep as it is, just for future error-proofing reasons. What if STUNT mislabels a step type? It's fine, because we have catching for those situations. After all, it's not like the unnecessary code will make anything wrong, it's just a bit more code we can keep in there.
noahsark769
commented
9 years ago "Unnecessary code is ALWAYS a problem" - Mark Twain
Brandon I disagree about this, I think we should definitely render the PDF based on what the format says rather than based on what the viewer thinks: that would break the entire abstraction. I don't think we need to over correct for STUNT charting a type wrong, and on the contrary I think we should always do whatever STUNT wants, whether it doesn't make sense or not, because at least then STUNT will be able to triage any issues themselves.
The reason why projects get bloated and not maintainable is because we leave in code that doesn't make sense just for fun :)
What do you think? On Thu, Feb 5, 2015 at 3:29 PM Brandon Chinn notifications@github.com wrote:
I think it's fine to keep as it is, just for future error-proofing reasons. What if STUNT mislabels a step type? It's fine, because we have catching for those situations. After all, it's not like the unnecessary code will make anything wrong, it's just a bit more code we can keep in there.
— Reply to this email directly or view it on GitHub https://github.com/calband/calchart-viewer/issues/161#issuecomment-73152674 .
brandonchinn178
commented
9 years ago Yea, sure, sounds fine. I just assumed you would prefer the catching just-in-case
noahsark769
commented
9 years ago Nope nope, with cal band code you gotta choose maintainability every time On Thu, Feb 5, 2015 at 5:11 PM Brandon Chinn notifications@github.com wrote:
Yea, sure, sounds fine. I just assumed you would prefer the catching just-in-case
— Reply to this email directly or view it on GitHub https://github.com/calband/calchart-viewer/issues/161#issuecomment-73163773 .
brandonchinn178
commented
9 years ago @kmdurand let me know when you fix calchart so i can fix the code
kmdurand
commented
9 years ago Yup, I'll let you know
brandonchinn178
commented
8 years ago @kmdurand status on this?
kmdurand
commented
8 years ago Lol haven't worked on this a ton. I'll try to check it out in the next few days and see what kind of time I'd need for this
brandonchinn178
commented
8 years ago maybe migrate to letting @dpgrubb13 and @belinda-liu work on this?
kmdurand
commented
7 years ago If they'd like to! @dpgrubb13 @belinda-liu What do you think?
rmpowell77
commented
4 months ago I've just added Close to CalChart with 3.7.1. Using this to add the close to CalChart Viewer.
The CalChart Online Viewer has been held back a little by the way that CalChart has been exporting viewer files. I'm updating CalChart in a couple ways right now that should improve things on the viewer side:
The main change that this will cause for the viewer, as far as I can tell, is the way that PDFs are generated. Correct me if I'm wrong, but I believe that the viewer currently looks at each even step command and convert it to a move command if the step size is right; that won't be necessary anymore, since all non-even step movements will be provided explicitly.