It depends how much futureproofness you want. I assume the code works as it is, but is becoming hard to make more changes. I suggest that you write out a table of all the possible inputs into the decision as to how to write the node out.

has parent  ||  is marked comment || node tag || etc...
[download]

On the right of the table, put all the possible results:

indent with tabs || newline before || etc.
[download]

Then, write out all the variations on the rows:

has parent	is marked comment	node tag	indent with tabs	newline before	...
yes	yes	a	yes	...
yes	yes	b	yes	...
...

Once you've done this, you should be able to see what the main factors are which decide the differences in output, and refactor accordingly. (You can also use this technique to model what your future changes will do.)

For example, if you find out that there are only 3 main output styles, then you can rewrite the subroutine to look at the inputs, and then call one of 3 subroutines (you could put them in a dispatch table in case you need more).

Or, if you think the decision is more complex, you might want to create objects to decide how to output the code. For example, you could create NodeWriter::HasParent to write out nodes with parents. Maybe table cell nodes are handled slightly different, so NodeWriter::HasParent::Td could inherit but override some methods. Then you can decide which object to create:

sub prepareOutput {
  my $self = shift;
  my ($node) = @_;
  my $writer = $self->create_nodewriter($node);
  $self->[OUTPUT] .= $writer->write_output($node);
}

sub create_nodewriter {
  my $self = shift;
  my ($node) = @_;
  $subtype = $node->parent? 'HasParent':'NoParent';
  $tagtype = ucfirst $node->tag;
  $class = "NodeWriter::$subtype" . "::$tagtype";
  return $class->new(); 
}
[download]

In short what I am suggesting is: "separate policy from mechanism".

A massive flamewar beneath your chosen depth has not been shown here