Menu
▾
▴
[Pcgen-trackers] [ pcgen-Bugs-1816661 ] Filters should not insert whitespace (" " or \n) into output
|
From: SourceForge.net <no...@so...> - 2008-12-01 15:07:39
|
Bugs item #1816661, was opened at 2007-10-19 17:37 Message generated for change (Comment added) made by karianna You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384719&aid=1816661&group_id=25576 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Export Character Group: To be fixed For 5.16.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: charles (chuckhazard) Assigned to: Martijn Verburg (karianna) Summary: Filters should not insert whitespace (" " or \n) into output Initial Comment: Starting a filter sends a newline to the output, so if you were to have the OS: --- begin innate spells |%SPELLLISTBOOK.0.0.1| innate spell stuff |%| --- end innate spells Your output for a race without innate spells would be: --- begin innate spells --- end innate spells This is counter-intuitive to me, as the filter is non printing it shouldn't send any output to the sheet just like a FOR tag doesn't take up any space. Also, if a filter is processed, the end filter tag |%| also takes up a newline. Using the example above, output for a race WITH innate spells would be: --- begin innate spells innate spell stuff --- end innate spells ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-12-01 15:07 Message: Hi Eddy, I see Nuance has already stated what I was going to say :). I'll work on the |SPACE| token (separate FREQ) but a majority of the OS problems such as Meleewaraxe (dwarven)+3(1d10+1/x3) can be solved with the nbsp; put in the right place. Obviously I didn't get all of the places correct. Can you attach or email me your sample character that is highlighting this bad spacing? ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-29 23:05 Message: Yes, that what MANUALWHITESPACE does, strip out any white spaces between a MANUALWHITESPACE and ENDMANUALWHITESPACE token. The exception is any spaces contained in the output of other tokens within that such as a two word object name. MANUALWHITESPACE is a good work around for these odd space issues but the non-breaking space is currently the only way to insert expected spaces back into the mix. ---------------------------------------------------------------------- Comment By: Andrew Wilson (nuance) Date: 2008-11-29 22:26 Message: No, there is no space entity. Any white space character at all other than the non-breaking space does what you want. If we're explicitly stripping out all whitespace apart from the non-breaking space then, yes, I think we need a |SPACE| token. All it needs to do is put in a space (ascii 32) character. ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-29 21:32 Message: You are correct, and that explains what I'm seeing. In my background as a non-programmer I was ignorant that that was what it was. So is there such a thing as an entity for a standard space? I can't seem to find one but if there is that would solve the issue. If not we need a SPACE token for that. ---------------------------------------------------------------------- Comment By: Andrew Wilson (nuance) Date: 2008-11-29 21:14 Message: Eddy, You keep calling that thing "the space entity", I have a feeling you're actually talking about the "non-breaking space". A browser is free to break content at all whitespace, that's the way html is designed. If you explicitly want to tell the browser "put a space here but never ever under any circumstances break these two words onto two lines" then you use a non-breaking space. That's what it's for. It seems like you're complaiunging that the non-breaking space does exactly what it's designed to do. ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-29 20:37 Message: Hi Kar. Using a space entity inside the MANUALWHITESPACE token will solve many (probably most) of the issues, but it needs to be done carefully or strange things can happen. For example you recent commit has turned this: Melee waraxe (dwarven) +3 (1d10+1 /x3 ) Into this: Meleewaraxe (dwarven)+3(1d10+1/x3) Also this does not address the problem I found with the space entity itself, that problem being that browsers do not recognize the space entity as a space for the purposes of creating breaks to wrap text. The problem is evident if you have a for loop that will generate a long list of abilities or whatever and the OS code outputs the spaces with space entities, the browsers will see the list as one long word and will not break it so what you get is ether the list will run on past the edge of the window or the browser will add a break at the beginning of the list and put the whole thing on a new line. If the list was long enough it could still run off past the window edge. This is the situation a SPACE token would be useful for. ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-28 16:25 Message: OK, Eddy I've committed all of the OS's I could find with your example problem and a bunch of others that I could quickly spot (upshot is that several of the sheets now have improvements in their formatting). I've also (I think) found a partial fix for the original problem that this tracker was actually about (printing white space when line is empty), so that is committed as well. I found no need to use a new SPACE token. If you're happy with the results, I'll move this tracker to OS, and close it and delete the SPACE Token FREQ. What a journey! ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-28 14:47 Message: Oh and incidentally yes the BR tag was enhanced, I think that may even have been me <shock horror>. Anyhow, I'm going to wrap the offending section in a MANUALWHITESPACE and see if the SPACE tag is actually necessary (if it is I'll implement it) or not (we'll only update OS's) ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-26 11:34 Message: James, yes you're right of course, I've been away from browser development way to long (does it show?). 'll tackle the freq that Eddy has raised, will keep this open until that is done (JIC it doesn't work). ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-25 21:28 Message: I've opened a FREQ for the SPACE token: [ 2346224 ] |SPACE| token to insert space characters https://sourceforge.net/tracker/index.php?func=detail&aid=2346224&group_id=25576&atid=384722 ---------------------------------------------------------------------- Comment By: James Dempsey (jdempsey) Date: 2008-11-25 21:21 Message: Hi Kar, Whitespace in HTML files is treated in a standard way by all browsers. Any number of whitespace characters (newlines, spaces, tabs) in a row are rendered as a single breaking space. IMO chasing down where spaces and newlines are output isn't a worth the time. We can use the MANUALWHITESPACE mode when necessary. I think if we want to spend that sort of effort on the output engine it would be better spent on a full upgrade to freemarker or velocity. I've also caught up with what happened to the BR tag. It was changed in late 2006 from my original of a new line to be a output style format dependant line break (so \n in text, <br> in html etc). Adding a |SPACE| tag which outputs a simpe space would provide the control that Eddy needs. Cheers, James. ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-25 11:38 Message: I'm pretty sure that won't work as a complete solution. Interestingly I can suppress the newLine output from the IIF token, add in manual whitespace at some parts of the OS template and things do improve a little. Unfortunately I can't do the same with the FOR node newlines as suppressing that makes the _source_ (viewable output is OKish) of the entire OS come out on one line (which is impossible to read/debug). I think I need to try and get to the heart of why the newlines are coming out as spaces / being interpreted as spaces and also majorly hack the ExportHandler etc so that it intelligently puts in newlines where needed. I'll keep working on it, but it's not going to be a quick fix. ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-24 17:26 Message: Would it be possible to create a |SPACE| token which would output a space character (not just a space entity)? It would have to work within MANUALWHITESPACE but it that could be done it would be possible to work around this problem without the issues that effect the space entity. ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-24 17:15 Message: OK, I've looked further and dug deeper. Basically I think we're hosed. * IIF Statements output newlines * FOR Statements output newlines In both cases the newlines sometimes are interpreted by browsers incorrectly as spaces but I cannot for the life of me tell why. If I suppress these newlines and either put in to make things look correct or use MANUALWHITESPACE then we run into the problems that Eddy describes below. Another major problem is that the source of the output sheet is then all on one line which is difficult to read to say the least. Not sure what else more I can offer :(, at least one minor side effect was a massive cleanup of the ExportHandler :) ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-20 20:47 Message: |BR| creates a line break, what we want is just a space. I tried this and |BR| outputs as <BR> in the html. ---------------------------------------------------------------------- Comment By: James Dempsey (jdempsey) Date: 2008-11-20 20:29 Message: You can use the |BR| tag to add breaking spaces in a HTML page. It adds a carriage return to the output, which browsers interpret as a breaking space. ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-20 16:35 Message: Ach! that entity cut off the rest of my comment. To continue, the problem with using the space entity is that although it looks like a space the browser does not treat it as such for the purposes of wrapping text. A series of words connected by the space entity rather than by actual spaces is treated as one long word which leads to strange line breaks. ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-20 16:04 Message: Just to note: one problem with enclosing stuff with MANUALWHITESPACE is that you have to add spaces back with a ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-20 15:26 Message: *Smacks Head* OK, they don't produce an actual Newline because in HTML you have to use a <br> tag, but the call to create the new line does introduce that space, although it doesn't really :). If you look at the source produced, it does not introduce a space, I believe it is actually the browser that does so (both FF and IE seem to do this). Not sure if this is 'solvable', it might have to be a case of wrapping affected areas in MANUALWHITESPACE tags in order to control what the output should look like. This whole area is an exercise in frustration, will be much better when we move to a real templating engine. ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-20 14:59 Message: Hmm, interesting, it appears that a Newline is being called by the ExportHandler after it processes certain 'things', but appears to be outputting a " " as opposed to a true newline. By commenting out that line the spaces went away, but they also did in places where we do need spaces :). If it was behaving as intended/coded then the output would actually look even stranger, for example instead of: ( human ) you'd get: ( human ) Now the newline call is actually a default Java API call, so this definitely will get interesting. ---------------------------------------------------------------------- Comment By: Martijn Verburg (karianna) Date: 2008-11-20 13:51 Message: Amended tracker title to cover both cases, am investigating as well (it's _nasty_), looks like we ahve plenty of formatting code in the core of PCGen (as opposed to the ExportHandler and below), so it's going to be a non trivial fix. ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-13 15:29 Message: Just to note, this tracker is about the OS tokens inserting unwanted returns, my comment below is from a tracker I opened which was marked as a duplicate of this. However the problem I am seeing is the OS tokens inserting unwanted 'space' characters. Seems like the problems may be related but if not please reopen the other tracker: New lines produce unwanted spaces in output https://sourceforge.net/tracker/?func=detail&atid=384719&aid=2276453&group_id=25576 ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-11-13 14:10 Message: To demonstrate create a human character and view the statblock4 sheet, here is the third line: TN medium humanoid ( human ) Note the spaces on either side of "human" within the parentheses. Here is the relevant code from the sheet: |ALIGNMENT.SHORT| |TEXT.LOWER.SIZELONG| |IIF(RACETYPE:None)| |TEXT.LOWER.TYPE| |ELSE| |TEXT.LOWER.RACETYPE| |ENDIF| |IIF(VAR.IF(var("COUNT[RACESUBTYPES]")==0;1;0):1)| |ELSE| ( |FOR,%subtype,0,COUNT[RACESUBTYPES]-2,1,1| |TEXT.LOWER.RACESUBTYPE.%subtype|, |ENDFOR| |FOR,%subtype,COUNT[RACESUBTYPES]-1,COUNT[RACESUBTYPES]-1,1,1| |TEXT.LOWER.RACESUBTYPE.%subtype| |ENDFOR| ) |ENDIF| <br> ---------------------------------------------------------------------- Comment By: Eddy Anthony (eddyanthony) Date: 2008-07-15 20:37 Message: Logged In: YES user_id=886893 Originator: NO This is a code bug or FREQ, moving. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=384719&aid=1816661&group_id=25576 |