Thanks Jesper, I think I have managed to fix the typos and indentation you pointed out so far, just a few comments/questions concerning more substantial issues ... >I wish you'd use an enum for the dominant direction type. Bool is fine if >you know the code intimately, but an enum makes for self documenting code. >Same goes for the return type of getVisDirection() OK, where do you suggest to put the typedef? >I'm not sure if this is the case, but won't >fp_Line::_createMapOfRuns() end up having a monstrously big >s_pMapOfRuns after a load/import? >The reason I ask is that on load/import all Runs of a paragraph is >stuffed into the same line, whereafter it is split up in mutiple lines as >necessary for the flow of the text. >If that does indeed affect your code, you'll end up with a large array (or >large arrays in the non-static version) which is never fully used after >the initial load. This would only happen if we have a very long paragraph with lot of formating changes. I will though add a mechanism to shrink the map if it is twice the default size and the current line in fact contains less runs than the default would accomodate; this should get rid of any huge maps without forcing unncessary delete/new all the time. The default size of the map is 80; currently the map element is UT_sint32 (I could change this to a signed character, if desired ...) >+ //if we follow a run that is consistent with the >+ direciton of the para, then so will be this //(dont have >+ to worry about the i-1 since this will never happen on >+ position 0 if(s_pMapOfRuns[i-1] == 0) >+ s_pMapOfRuns[i] = 0; > Why? Can't a space be the first thing on a line? Yes, it can, but if the first run is directionally neutral, the code that precedes this has already set its direction to the dominant direction of the paragraph; I will expand the comment to make this clear. Further comments are eagerly awaited. Tomas
