As already mentioned, there is zero impact on the log chain if you shrink the transaction log. But the question remains, why do you want to shrink the transaction log? Other than doing restores to other environments with inadequate space, there really isn't a good reason to shrink the transaction log. It grows to a certain size because it requires that amount of space to log transactions until the next transaction log backup occurs.

Typically, the index maintenance process is what causes it to grow the most. Make sure that you have a smart index maintenance process in place and do not just use the database maintenance wizard so that you are only rebuilding the indexes that are fragmented. Rebuilding an index that isn't fragmented generates a lot of unnecessary entries in the transaction log.

Check out the following two BLOGS by Kimberly Tripp:

http://www.sqlskills.com/blogs/kimberly/post/8-Steps-to-better-Transaction-Log-throughput.aspx

This one contains links to several smart index maintenance processes.

http://www.sqlskills.com/blogs/kimberly/post/Database-Maintenance-Best-Practices-Part-I-e28093-clarifying-ambiguous-recommendations-for-Sharepoint.aspx

You can also check out Ola Hallengren's scripts. I know a lot of DBA's who have implemented his maintenance scripts.

http://ola.hallengren.com/